)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7ea4cc6fd46b00a59d4b396c127b7aace61e4ef2","unresolved":false,"context_lines":[{"line_number":16,"context_line":"This test shows that is not a regression because the"},{"line_number":17,"context_line":"AvailabilityZoneFilter looks at RequestSpec.availability_zone"},{"line_number":18,"context_line":"rather than instance.availabililty_zone, so the instance"},{"line_number":19,"context_line":"is free to be moved across zones."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"As a result of the test, however, it was noticed that"},{"line_number":22,"context_line":"the instance.availability_zone isn\u0027t updated during live"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"5fc1f717_9c93ac5b","line":19,"updated":"2019-03-12 15:58:07.000000000","message":"You\u0027re saying that after moving an instance across zones, you won\u0027t break it and it will continue to re-schedule within that zone properly (like if you did a resize) right? This is actually just for display and/or metadata I guess yeah?","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c056387ec2e6bf9c978bf2b56f213d6f49ae0275","unresolved":false,"context_lines":[{"line_number":16,"context_line":"This test shows that is not a regression because the"},{"line_number":17,"context_line":"AvailabilityZoneFilter looks at RequestSpec.availability_zone"},{"line_number":18,"context_line":"rather than instance.availabililty_zone, so the instance"},{"line_number":19,"context_line":"is free to be moved across zones."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"As a result of the test, however, it was noticed that"},{"line_number":22,"context_line":"the instance.availability_zone isn\u0027t updated during live"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"5fc1f717_3f338af8","line":19,"in_reply_to":"5fc1f717_9c93ac5b","updated":"2019-03-12 16:19:22.000000000","message":"If the server was created without an explicit AZ, RequestSpec.availability_zone will be None and never change after that, and that\u0027s what the AZ filter looks at, not the instance.availability_zone (and yeah as far as I know that\u0027s only used for display from the servers API):\n\nhttps://github.com/openstack/nova/blob/e608568518ed91a0cbf08f779c5adb851762d80a/nova/scheduler/filters/availability_zone_filter.py#L41\n\nSo even if you live migrate across zones, you can resize to another zone.","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7ea4cc6fd46b00a59d4b396c127b7aace61e4ef2","unresolved":false,"context_lines":[{"line_number":22,"context_line":"the instance.availability_zone isn\u0027t updated during live"},{"line_number":23,"context_line":"migration once the destination host is selected. The other"},{"line_number":24,"context_line":"move operations like unshelve, evacuate and cold migrate"},{"line_number":25,"context_line":"all update the instance.availabiltiy_zone, so this copies"},{"line_number":26,"context_line":"the same logic."},{"line_number":27,"context_line":""},{"line_number":28,"context_line":"Change-Id: I9f73c237923fdcbf4096edc5aedd2c968d4b893e"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":5,"id":"5fc1f717_fcd43022","line":25,"range":{"start_line":25,"start_character":24,"end_line":25,"end_character":41},"updated":"2019-03-12 15:58:07.000000000","message":"availability_zone","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"}],"nova/conductor/tasks/live_migrate.py":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7ea4cc6fd46b00a59d4b396c127b7aace61e4ef2","unresolved":false,"context_lines":[{"line_number":119,"context_line":""},{"line_number":120,"context_line":"        self.instance.availability_zone \u003d ("},{"line_number":121,"context_line":"            availability_zones.get_host_availability_zone("},{"line_number":122,"context_line":"                self.context, self.destination))"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"        self.migration.source_node \u003d self.instance.node"},{"line_number":125,"context_line":"        self.migration.dest_node \u003d dest_node"}],"source_content_type":"text/x-python","patch_set":5,"id":"5fc1f717_dc5cd4ee","line":122,"updated":"2019-03-12 15:58:07.000000000","message":"Is this the right place to do this? We\u0027re about to make a cast below, which could get dropped, or fail for any number of reasons, and then we won\u0027t change this back, right? I would expect that we should do the az change when we change the actual instance.host and this seems super early, no?\n\nIf we do do it here, I would think we need to un-do it in the fallback cases.","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"cb9d928e7c61e666c2ab51f9fee0c134c035f119","unresolved":false,"context_lines":[{"line_number":119,"context_line":""},{"line_number":120,"context_line":"        self.instance.availability_zone \u003d ("},{"line_number":121,"context_line":"            availability_zones.get_host_availability_zone("},{"line_number":122,"context_line":"                self.context, self.destination))"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"        self.migration.source_node \u003d self.instance.node"},{"line_number":125,"context_line":"        self.migration.dest_node \u003d dest_node"}],"source_content_type":"text/x-python","patch_set":5,"id":"ffb9cba7_3e0a0cd2","line":122,"in_reply_to":"5fc1f717_7f8a72bf","updated":"2019-04-23 20:24:46.000000000","message":"FWIW I came across https://review.opendev.org/#/c/491226/ today and it does what Dan was suggesting, which is not set the instance.availability_zone until we set the instance.host during post_live_migration, and as noted that would be an up-call or an RPC API version change (which we can\u0027t backport). Now that we\u0027re on master, we could pass the az down to avoid the up-call and still only set the az once we set the host in post_live_migration (I don\u0027t plan on working on that anytime soon though and it\u0027s a problem in all of these move operations).","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"fc73efe5f6d8295eeb50a4ad6c81de8776582964","unresolved":false,"context_lines":[{"line_number":119,"context_line":""},{"line_number":120,"context_line":"        self.instance.availability_zone \u003d ("},{"line_number":121,"context_line":"            availability_zones.get_host_availability_zone("},{"line_number":122,"context_line":"                self.context, self.destination))"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"        self.migration.source_node \u003d self.instance.node"},{"line_number":125,"context_line":"        self.migration.dest_node \u003d dest_node"}],"source_content_type":"text/x-python","patch_set":5,"id":"5fc1f717_7f8a72bf","line":122,"in_reply_to":"5fc1f717_bf253a5e","updated":"2019-03-12 16:45:27.000000000","message":"\u003e Would it not be better to just put this down where we set the host?\n\nProbably, but that\u0027s either a (1) up-call which we try to avoid or (2) an RPC change which is not backportable.\n\n \u003e And if not, shouldn\u0027t we just put something in the fallback handler\n \u003e to set it back? We might need that for the cold operations too, I\u0027d\n \u003e have to go look. I guess for the former we need to pass it\n \u003e separately over the wire so compute can do it, and maybe that\u0027s why\n \u003e I didn\u0027t..\n\nSaving off the original AZ and resetting it back in rollback seems fine in case migration.save() or the cast fails, and as noted that should be done in the other operations as well.","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ab811f6be3e3fad504d6393ca2f33e509bb39bc8","unresolved":false,"context_lines":[{"line_number":119,"context_line":""},{"line_number":120,"context_line":"        self.instance.availability_zone \u003d ("},{"line_number":121,"context_line":"            availability_zones.get_host_availability_zone("},{"line_number":122,"context_line":"                self.context, self.destination))"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"        self.migration.source_node \u003d self.instance.node"},{"line_number":125,"context_line":"        self.migration.dest_node \u003d dest_node"}],"source_content_type":"text/x-python","patch_set":5,"id":"5fc1f717_df112606","line":122,"in_reply_to":"5fc1f717_bf545aff","updated":"2019-03-12 16:26:15.000000000","message":"\u003e I would expect that we should do the az change when we change the actual instance.host\n\nThat would be an up-call unless we pass the az down to the compute, which is another issue we already have (bug 1781286).","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6b22340b91a8fa34e62e7612adc423e1f55b6f9f","unresolved":false,"context_lines":[{"line_number":119,"context_line":""},{"line_number":120,"context_line":"        self.instance.availability_zone \u003d ("},{"line_number":121,"context_line":"            availability_zones.get_host_availability_zone("},{"line_number":122,"context_line":"                self.context, self.destination))"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"        self.migration.source_node \u003d self.instance.node"},{"line_number":125,"context_line":"        self.migration.dest_node \u003d dest_node"}],"source_content_type":"text/x-python","patch_set":5,"id":"5fc1f717_bf253a5e","line":122,"in_reply_to":"5fc1f717_bf545aff","updated":"2019-03-12 16:31:19.000000000","message":"I feel like resize/migrate is a little more of I \"expect it to complete\" where live migration is \"expect it to fail\", both because of the somewhat auto-revert behavior of it, as well as the async \"let the two computes sort it out\" sort of model. But yeah, fair enough, it\u0027s basically the same.\n\nWould it not be better to just put this down where we set the host? And if not, shouldn\u0027t we just put something in the fallback handler to set it back? We might need that for the cold operations too, I\u0027d have to go look. I guess for the former we need to pass it separately over the wire so compute can do it, and maybe that\u0027s why I didn\u0027t..","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c056387ec2e6bf9c978bf2b56f213d6f49ae0275","unresolved":false,"context_lines":[{"line_number":119,"context_line":""},{"line_number":120,"context_line":"        self.instance.availability_zone \u003d ("},{"line_number":121,"context_line":"            availability_zones.get_host_availability_zone("},{"line_number":122,"context_line":"                self.context, self.destination))"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"        self.migration.source_node \u003d self.instance.node"},{"line_number":125,"context_line":"        self.migration.dest_node \u003d dest_node"}],"source_content_type":"text/x-python","patch_set":5,"id":"5fc1f717_bf545aff","line":122,"in_reply_to":"5fc1f717_dc5cd4ee","updated":"2019-03-12 16:19:22.000000000","message":"This is no different from how you did this for the other move operations in the change referenced in the commit message. I asked you about this somewhat recently too and the assumption is that the change will get persisted when the compute saves changes to the instance, like when setting task_state to None for example.","commit_id":"0ed68c76fa8a84d1d5f0ab945e34c8e16341d627"}],"nova/tests/functional/test_availability_zones.py":[{"author":{"_account_id":6167,"name":"Ken\u0027ichi Ohmichi","email":"ken1ohmichi@gmail.com","username":"oomichi"},"change_message_id":"799be91f6f678c461d5f73ee1d9318b3811a1312","unresolved":false,"context_lines":[{"line_number":117,"context_line":""},{"line_number":118,"context_line":"        # Assert that the server did move."},{"line_number":119,"context_line":"        server \u003d self.api.get_server(server[\u0027id\u0027])"},{"line_number":120,"context_line":"        expected_host \u003d \u0027host1\u0027 if original_host \u003d\u003d \u0027host2\u0027 else \u0027host2\u0027"},{"line_number":121,"context_line":"        self.assertEqual(expected_host, server[\u0027OS-EXT-SRV-ATTR:host\u0027])"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_d96a6e18","line":121,"range":{"start_line":120,"start_character":0,"end_line":121,"end_character":71},"updated":"2018-05-14 18:04:09.000000000","message":"Why not check \u0027OS-EXT-AZ:availability_zone\u0027 instead of \u0027OS-EXT-SRV-ATTR:host\u0027? This question comes from line 101 checks the host instead of the az before the live-migration.","commit_id":"51b103e73a9fa000f0facc65b21f65ca5e7c31e1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4f56d3e3a9d1950e29efba2b9fd6bcd32ec98d0c","unresolved":false,"context_lines":[{"line_number":117,"context_line":""},{"line_number":118,"context_line":"        # Assert that the server did move."},{"line_number":119,"context_line":"        server \u003d self.api.get_server(server[\u0027id\u0027])"},{"line_number":120,"context_line":"        expected_host \u003d \u0027host1\u0027 if original_host \u003d\u003d \u0027host2\u0027 else \u0027host2\u0027"},{"line_number":121,"context_line":"        self.assertEqual(expected_host, server[\u0027OS-EXT-SRV-ATTR:host\u0027])"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_fdeee9b2","line":121,"range":{"start_line":120,"start_character":0,"end_line":121,"end_character":71},"in_reply_to":"5f7c97a3_d96a6e18","updated":"2018-05-17 15:48:56.000000000","message":"I could check the AZ in addition to (or instead of) the host, sure.","commit_id":"51b103e73a9fa000f0facc65b21f65ca5e7c31e1"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"57500c4f92f96fc5e3b1414f12d195669e13ce40","unresolved":false,"context_lines":[{"line_number":117,"context_line":""},{"line_number":118,"context_line":"        # Assert that the server did move."},{"line_number":119,"context_line":"        server \u003d self.api.get_server(server[\u0027id\u0027])"},{"line_number":120,"context_line":"        expected_host \u003d \u0027host1\u0027 if original_host \u003d\u003d \u0027host2\u0027 else \u0027host2\u0027"},{"line_number":121,"context_line":"        self.assertEqual(expected_host, server[\u0027OS-EXT-SRV-ATTR:host\u0027])"}],"source_content_type":"text/x-python","patch_set":1,"id":"5f7c97a3_386f8f93","line":121,"range":{"start_line":120,"start_character":0,"end_line":121,"end_character":71},"in_reply_to":"5f7c97a3_fdeee9b2","updated":"2018-05-17 16:13:53.000000000","message":"Excellent catch Ken\u0027ichi - it turns out the live migration operation wasn\u0027t changing the instance.availability_zone when the instance moved zones, so I\u0027ll have to fix that as part of this.","commit_id":"51b103e73a9fa000f0facc65b21f65ca5e7c31e1"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f8d9302b38b4b3c1c1913500440386ba0d1ea9e2","unresolved":false,"context_lines":[{"line_number":86,"context_line":"        \"\"\""},{"line_number":87,"context_line":"        # Start two compute services in separate zones."},{"line_number":88,"context_line":"        self._start_host_in_zone(\u0027host1\u0027, \u0027zone1\u0027)"},{"line_number":89,"context_line":"        self._start_host_in_zone(\u0027host2\u0027, \u0027zone2\u0027)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"        # Create a server, it doesn\u0027t matter which host it ends up in."},{"line_number":92,"context_line":"        server_body \u003d self._build_minimal_create_server_request("}],"source_content_type":"text/x-python","patch_set":3,"id":"3f79a3b5_024df2c4","line":89,"updated":"2018-12-19 21:46:06.000000000","message":"I wondered if we could possibly race here since we\u0027re not waiting for the compute host to be added to the aggregate. The add_host_to_aggregate call makes an RPC cast to compute add_aggregate_host, but all that does is call self.driver.add_to_aggregate and only the xenapi driver implements it. Otherwise, it\u0027s a no-op.\n\nSo, all of the relevant updates for this test are done synchronously in compute/api, so no race issue.","commit_id":"bfe79692a587432b24162ac40428a0974320638d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"69fba5a989fb0ae165e44f1f40175dc68188abb2","unresolved":false,"context_lines":[{"line_number":86,"context_line":"        \"\"\""},{"line_number":87,"context_line":"        # Start two compute services in separate zones."},{"line_number":88,"context_line":"        self._start_host_in_zone(\u0027host1\u0027, \u0027zone1\u0027)"},{"line_number":89,"context_line":"        self._start_host_in_zone(\u0027host2\u0027, \u0027zone2\u0027)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"        # Create a server, it doesn\u0027t matter which host it ends up in."},{"line_number":92,"context_line":"        server_body \u003d self._build_minimal_create_server_request("}],"source_content_type":"text/x-python","patch_set":3,"id":"3f79a3b5_fd6097d3","line":89,"in_reply_to":"3f79a3b5_024df2c4","updated":"2018-12-19 21:52:27.000000000","message":"We don\u0027t care about the RPC cast to compute stuff, we just care about the DB changes, which happens here:\n\nhttps://github.com/openstack/nova/blob/86da9c72c1549aeac8b09b10fa24ce8990db2097/nova/compute/api.py#L5452\n\nhttps://github.com/openstack/nova/blob/86da9c72c1549aeac8b09b10fa24ce8990db2097/nova/objects/aggregate.py#L395","commit_id":"bfe79692a587432b24162ac40428a0974320638d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"b782e7bc7fa5cc116b28c0753d6281e91e0f15f3","unresolved":false,"context_lines":[{"line_number":86,"context_line":"        \"\"\""},{"line_number":87,"context_line":"        # Start two compute services in separate zones."},{"line_number":88,"context_line":"        self._start_host_in_zone(\u0027host1\u0027, \u0027zone1\u0027)"},{"line_number":89,"context_line":"        self._start_host_in_zone(\u0027host2\u0027, \u0027zone2\u0027)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"        # Create a server, it doesn\u0027t matter which host it ends up in."},{"line_number":92,"context_line":"        server_body \u003d self._build_minimal_create_server_request("}],"source_content_type":"text/x-python","patch_set":3,"id":"3f79a3b5_3dd04f29","line":89,"in_reply_to":"3f79a3b5_ddafdbc5","updated":"2018-12-19 22:06:08.000000000","message":"Oh sorry I was confused.","commit_id":"bfe79692a587432b24162ac40428a0974320638d"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4301b46855e7dca5cb28b20fb71aaa97f670c26a","unresolved":false,"context_lines":[{"line_number":86,"context_line":"        \"\"\""},{"line_number":87,"context_line":"        # Start two compute services in separate zones."},{"line_number":88,"context_line":"        self._start_host_in_zone(\u0027host1\u0027, \u0027zone1\u0027)"},{"line_number":89,"context_line":"        self._start_host_in_zone(\u0027host2\u0027, \u0027zone2\u0027)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"        # Create a server, it doesn\u0027t matter which host it ends up in."},{"line_number":92,"context_line":"        server_body \u003d self._build_minimal_create_server_request("}],"source_content_type":"text/x-python","patch_set":3,"id":"3f79a3b5_ddafdbc5","line":89,"in_reply_to":"3f79a3b5_fd6097d3","updated":"2018-12-19 21:59:11.000000000","message":"Right. I said the same thing, I thought: \"all of the relevant updates for this test are done synchronously in compute/api, so no race issue.\"\n\nBut, nice to have the links to the DB changes for reference here.","commit_id":"bfe79692a587432b24162ac40428a0974320638d"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"2fca472f950190ed9f1a2f6e777c96287e09d79b","unresolved":false,"context_lines":[{"line_number":28,"context_line":""},{"line_number":29,"context_line":"        self.useFixture(policy_fixture.RealPolicyFixture())"},{"line_number":30,"context_line":"        self.useFixture(nova_fixtures.NeutronFixture(self))"},{"line_number":31,"context_line":"        self.useFixture(nova_fixtures.PlacementFixture())"},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"        api_fixture \u003d self.useFixture(nova_fixtures.OSAPIFixture("},{"line_number":34,"context_line":"            api_version\u003d\u0027v2.1\u0027))"}],"source_content_type":"text/x-python","patch_set":4,"id":"3f79a3b5_a538c538","line":31,"range":{"start_line":31,"start_character":8,"end_line":31,"end_character":57},"updated":"2018-12-20 02:15:36.000000000","message":"This one is from nova.tests.functional.fixture","commit_id":"11bd81b8b989791d8559733124a54b651c95923d"}]}