)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":38081,"name":"Anthony Galica","display_name":"agalica","email":"anthony.galica@hitachivantara.com","username":"agalica","status":"Hitachi Vantara"},"change_message_id":"fb1ee69ca0d2a185be0332e0120803ccdaa95eea","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"218c9d6c_4dd30931","updated":"2026-10-02 15:23:51.000000000","message":"I think this change does make sense for the multi-driver case, but are we sure that drivers that migrate from the same driver to a different backend won\u0027t be affected by this change?","commit_id":"525fc40e91e9db262ff7228394b5352929883818"},{"author":{"_account_id":13425,"name":"Simon Dodsley","email":"simon@everpuredata.com","username":"sdodsley"},"change_message_id":"afd2b8452f6acf196d0fd5284db305b6073cda60","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"589a5273_bef259f8","updated":"2026-09-18 15:53:37.000000000","message":"makes sense","commit_id":"525fc40e91e9db262ff7228394b5352929883818"},{"author":{"_account_id":29071,"name":"norman shen","email":"yshxxsjt715@gmail.com","username":"ushen"},"change_message_id":"cc520482d537a6213ef00e234dbd7d7aa141641c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a8938a99_de202f76","in_reply_to":"218c9d6c_4dd30931","updated":"2026-10-14 02:35:42.000000000","message":"I can understand the concern, but I do not have enough resource to verify. Can you provide some idea？ thank you.","commit_id":"525fc40e91e9db262ff7228394b5352929883818"},{"author":{"_account_id":13425,"name":"Simon Dodsley","email":"simon@everpuredata.com","username":"sdodsley"},"change_message_id":"bc325d76fe7ef42598800a5e77d4f179ddf70a89","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e5107415_d63b6ae7","in_reply_to":"a8938a99_de202f76","updated":"2026-10-14 19:14:06.000000000","message":"I looked at this for the same-driver, different-backend case. The destination volume\u0027s `provider_location` is written by the destination driver\u0027s `create_volume`, and across all 65 drivers that use the field none reads it as an input to `create_volume` (remotefs, NetApp NFS, Hitachi, Huawei, PowerFlex, 3PAR, XtremIO all assign it unconditionally). `update_migrated_volume` implementations either compute it fresh or echo `new_volume.provider_location`, which is that same value. So for A→B on one driver the result is identical with or without this change.\n\nWhat changes is the failure path: today a temp volume whose create failed still carries the source array\u0027s `provider_location`, and `_clean_temporary_volume` deletes it on the destination backend. For HBSD that means `get_ldev()` resolving a source-array LDEV number on the destination array, saved only by the label check in `is_invalid_ldev`. With this change the temp volume has no `provider_location`, so that cannot happen.\n\n`cinder-tempest-lvm-multibackend` (LVM→LVM generic migration between two backends) passed on PS1, and `test_volume_migration` passes locally on the patched tree. I\u0027d ask for a unit test asserting the temp volume is created without `provider_location`, and a rebase, but the change itself is safe.","commit_id":"525fc40e91e9db262ff7228394b5352929883818"},{"author":{"_account_id":38081,"name":"Anthony Galica","display_name":"agalica","email":"anthony.galica@hitachivantara.com","username":"agalica","status":"Hitachi Vantara"},"change_message_id":"17780ed3bbd60cc5b84ed479098476975123377b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f22ec4c4_8fd62858","in_reply_to":"e5107415_d63b6ae7","updated":"2026-10-14 19:39:45.000000000","message":"Good analysis, Simon.\n\n@yshxxsjt715@gmail.com, can you provide the UT that Simon is asking about and rebase the patch?","commit_id":"525fc40e91e9db262ff7228394b5352929883818"}]}