)]}'
{"cinder/volume/drivers/vzstorage.py":[{"author":{"_account_id":11904,"name":"Sean McGinnis","email":"sean.mcginnis@gmail.com","username":"SeanM"},"change_message_id":"4f961b38cb55ee994249021cc18c94c00281c917","unresolved":false,"context_lines":[{"line_number":704,"context_line":""},{"line_number":705,"context_line":"        self._create_snapshot_ploop(temp_snapshot)"},{"line_number":706,"context_line":"        try:"},{"line_number":707,"context_line":"            volume.provider_location \u003d src_vref.provider_location"},{"line_number":708,"context_line":"            info_path \u003d self._local_path_volume_info(volume)"},{"line_number":709,"context_line":"            snap_info \u003d {\u0027active\u0027: \u0027volume-%s\u0027 % volume.id}"},{"line_number":710,"context_line":"            self._write_info_file(info_path, snap_info)"}],"source_content_type":"text/x-python","patch_set":1,"id":"9f436f4f_2381e24b","line":707,"updated":"2017-08-17 14:38:41.000000000","message":"This can probably be removed now, right?\n\nI\u0027m a little confused tracing through here. Where is provider_location used? It seems odd that the cloned volume would have the same provider_location as the original volume, but I don\u0027t know enough here to understand how it\u0027s being used.\n\nSeems like a new provider_location would need to be set based on the new volume information, then just returned in the model update for the calls return.","commit_id":"d452fc91510576837f235a218356918e99b129a0"},{"author":{"_account_id":13431,"name":"Evgeny Antyshev","email":"eantyshev@gmail.com","username":"eantyshev"},"change_message_id":"e3d6b6a7e52e65482e4eb1eff261966b1e609ca7","unresolved":false,"context_lines":[{"line_number":704,"context_line":""},{"line_number":705,"context_line":"        self._create_snapshot_ploop(temp_snapshot)"},{"line_number":706,"context_line":"        try:"},{"line_number":707,"context_line":"            volume.provider_location \u003d src_vref.provider_location"},{"line_number":708,"context_line":"            info_path \u003d self._local_path_volume_info(volume)"},{"line_number":709,"context_line":"            snap_info \u003d {\u0027active\u0027: \u0027volume-%s\u0027 % volume.id}"},{"line_number":710,"context_line":"            self._write_info_file(info_path, snap_info)"}],"source_content_type":"text/x-python","patch_set":1,"id":"9f436f4f_e3507a61","line":707,"in_reply_to":"9f436f4f_2381e24b","updated":"2017-08-17 14:57:53.000000000","message":"I didn\u0027t quite get it all yet.\n\nBy this moment I can say:\nPrimary issue is provider_location \u003d None for volume created by create_cloned_volume (through _create_from_source_volume() from flows/manager/create_volume.py) for all subclasses of remotefs.\nThe above line fixes this same thing for Ploop, but for QCOW2 we use _create_cloned_volume from remotefs, and it doesn\u0027t define provider_location.\n\nSeems like a bug of remotefs. To compare with, _create_from_snapshot -\u003e create_volume_from_snapshot() from remotefs defines provider_location","commit_id":"d452fc91510576837f235a218356918e99b129a0"}]}