)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"0cc343d2e04c5053d7c5b488e8acc1afc3c861bf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"8b60e1e3_7989f16a","updated":"2026-06-16 22:00:17.000000000","message":"Seems like a bug in the cinder code but there is no easy way to fix it.","commit_id":"50b1045e869a42eae86addf6ed0d56047845b793"}],"cinder_tempest_plugin/api/volume/admin/test_volume_replication.py":[{"author":{"_account_id":27615,"name":"Rajat Dhasmana","email":"rajatdhasmana@gmail.com","username":"whoami-rajat"},"change_message_id":"0cc343d2e04c5053d7c5b488e8acc1afc3c861bf","unresolved":true,"context_lines":[{"line_number":185,"context_line":"        \"\"\"Test cloning volume on secondary backend after failover.\"\"\""},{"line_number":186,"context_line":"        volume \u003d self._create_replicated_volume()"},{"line_number":187,"context_line":"        self._failover_host(volume)"},{"line_number":188,"context_line":"        cloned_volume \u003d self.create_volume(source_volid\u003dvolume[\u0027id\u0027])"},{"line_number":189,"context_line":"        cloned_vol_details \u003d self.volumes_client.show_volume("},{"line_number":190,"context_line":"            cloned_volume[\u0027id\u0027])[\u0027volume\u0027]"},{"line_number":191,"context_line":"        self.assertEqual(cloned_vol_details[\u0027source_volid\u0027], volume[\u0027id\u0027])"}],"source_content_type":"text/x-python","patch_set":1,"id":"d54e2e0f_cc993f39","line":188,"range":{"start_line":188,"start_character":8,"end_line":188,"end_character":69},"updated":"2026-06-16 22:00:17.000000000","message":"this operation fails and there are 2 issues due to which it happens:\n1. The volume type used is replicated but after the failover, we move to a non-replicated cluster so filter scheduler fails. This can be fixed by creating a non-replicated volume type and passing it with this method\n\n    Jun 16 19:57:16 rbd-repl-v3 cinder-scheduler[1222956]: DEBUG cinder.scheduler.filters.capabilities_filter [None req-f95917a8-227f-4e9f-9ef4-013521652eeb tempest-VolumeReplicationTest-1111383752 None] Volume type extra spec requirement \"replication_enabled\u003d\u003cis\u003e True\" does not match reported capability \"False\" {{(pid\u003d1222956) _satisfies_extra_specs /opt/stack/cinder/cinder/scheduler/filters/capabilities_filter.py:86}}\n\n2. Even after we bypass the above issue, we fail while weighing since we expect the clone to be created in the same backend as the source volume. Unfortunately the host information for source isn\u0027t updated (seems like there is no easy way to do so as well) so we try to create the clone in primary backend which fails since it\u0027s disabled and source volume exists in secondary cluster whereas the host field says otherwise.","commit_id":"50b1045e869a42eae86addf6ed0d56047845b793"},{"author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"tag":"autogenerated:zuul:check","change_message_id":"706e2362d5c901ebc96607fb6978344df7f95470","unresolved":false,"context_lines":[{"line_number":204,"context_line":"                                          migration_policy\u003d\u0027on-demand\u0027)"},{"line_number":205,"context_line":"        waiters.wait_for_volume_replication_status("},{"line_number":206,"context_line":"            self.volumes_client, volume[\u0027id\u0027], \u0027disabled\u0027)"},{"line_number":207,"context_line":""}],"source_content_type":"text/x-python","patch_set":1,"id":"15e14e49_4300a7d2","line":207,"updated":"2026-06-16 22:03:16.000000000","message":"pep8: W391 blank line at end of file","commit_id":"50b1045e869a42eae86addf6ed0d56047845b793"}]}