)]}'
{"specs/stein/approved/cross-cell-resize.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":86,"context_line":"This describes the flow of a resize up until the point that the server"},{"line_number":87,"context_line":"goes to ``VERIFY_RESIZE`` status."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The API will perform its normal checks and call the conductor"},{"line_number":90,"context_line":"  ``MigrationTask`` which will check if the user is allowed, by the new"},{"line_number":91,"context_line":"  policy rule, to perform a cross-cell resize. If so, the task will modify"},{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_283dc8b8","line":91,"range":{"start_line":89,"start_character":54,"end_line":91,"end_character":13},"updated":"2018-12-03 20:41:28.000000000","message":"I\u0027ve done zero checking to confirm, but would this be an unusual policy check outside of the api nodes? I ask because if so, the api nodes may have a full policy file but conductor nodes do not.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":86,"context_line":"This describes the flow of a resize up until the point that the server"},{"line_number":87,"context_line":"goes to ``VERIFY_RESIZE`` status."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The API will perform its normal checks and call the conductor"},{"line_number":90,"context_line":"  ``MigrationTask`` which will check if the user is allowed, by the new"},{"line_number":91,"context_line":"  policy rule, to perform a cross-cell resize. If so, the task will modify"},{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_8ecc25be","line":91,"range":{"start_line":89,"start_character":54,"end_line":91,"end_character":13},"in_reply_to":"3f79a3b5_283dc8b8","updated":"2018-12-03 22:17:31.000000000","message":"The one other definitely-not-in-api-code policy check I know of off the top of my head is this one:\n\nhttps://github.com/openstack/nova/blob/1e8c2c0dcb3ff9225407b890a6c99658b35764bc/nova/network/neutronv2/api.py#L585\n\nAnd that happens on nova-compute during allocate_for_instance.\n\nWe probably don\u0027t have to do it in the cold migrate conductor task code, this is where I\u0027m doing it now:\n\nhttps://review.openstack.org/#/c/603930/17/nova/conductor/tasks/migrate.py@202\n\nIt just fit naturally with restricting the request spec to the source cell or not, but we could also modify the request spec from the resize_instance method in the API and pass that down to conductor.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":86,"context_line":"This describes the flow of a resize up until the point that the server"},{"line_number":87,"context_line":"goes to ``VERIFY_RESIZE`` status."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The API will perform its normal checks and call the conductor"},{"line_number":90,"context_line":"  ``MigrationTask`` which will check if the user is allowed, by the new"},{"line_number":91,"context_line":"  policy rule, to perform a cross-cell resize. If so, the task will modify"},{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d9c6086b","line":91,"range":{"start_line":89,"start_character":54,"end_line":91,"end_character":13},"in_reply_to":"3f79a3b5_3c6375e2","updated":"2018-12-20 10:12:55.000000000","message":"Yeah, seems your current code could also work in API","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":86,"context_line":"This describes the flow of a resize up until the point that the server"},{"line_number":87,"context_line":"goes to ``VERIFY_RESIZE`` status."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The API will perform its normal checks and call the conductor"},{"line_number":90,"context_line":"  ``MigrationTask`` which will check if the user is allowed, by the new"},{"line_number":91,"context_line":"  policy rule, to perform a cross-cell resize. If so, the task will modify"},{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_3c6375e2","line":91,"range":{"start_line":89,"start_character":54,"end_line":91,"end_character":13},"in_reply_to":"3f79a3b5_8ecc25be","updated":"2018-12-20 00:10:11.000000000","message":"Based on this, it seems like it would be more expected and fit in better with our existing policy checks to have the policy check in the API and modify the request spec there before passing it down. Otherwise, it would be more akin to a one-off and possibly more difficult to keep track of and maintain. The conductor quota recheck comes to mind along these lines. People are often confused to find a quota check in conductor.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":86,"context_line":"This describes the flow of a resize up until the point that the server"},{"line_number":87,"context_line":"goes to ``VERIFY_RESIZE`` status."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The API will perform its normal checks and call the conductor"},{"line_number":90,"context_line":"  ``MigrationTask`` which will check if the user is allowed, by the new"},{"line_number":91,"context_line":"  policy rule, to perform a cross-cell resize. If so, the task will modify"},{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_f55df9e4","line":91,"range":{"start_line":89,"start_character":54,"end_line":91,"end_character":13},"in_reply_to":"3f79a3b5_d9c6086b","updated":"2018-12-20 20:39:00.000000000","message":"Yeah I plan on changing to move the policy check to the API as it\u0027s also needed for the case that the admin passes a host during cold migrate and that host is in another cell (open question #2 below).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":86,"context_line":"This describes the flow of a resize up until the point that the server"},{"line_number":87,"context_line":"goes to ``VERIFY_RESIZE`` status."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The API will perform its normal checks and call the conductor"},{"line_number":90,"context_line":"  ``MigrationTask`` which will check if the user is allowed, by the new"},{"line_number":91,"context_line":"  policy rule, to perform a cross-cell resize. If so, the task will modify"},{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_d8842461","line":91,"range":{"start_line":89,"start_character":54,"end_line":91,"end_character":13},"in_reply_to":"3f79a3b5_f55df9e4","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  .. note:: A new ``CrossCellWeigher`` will be introduced which will prefer"},{"line_number":96,"context_line":"      hosts from the source cell. Since a cross-cell resize is more"},{"line_number":97,"context_line":"      complicated / expensive than a normal resize, we always want to use"},{"line_number":98,"context_line":"      hosts from the source cell if possible. This weigher will be a noop"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_889c1cbf","line":95,"range":{"start_line":95,"start_character":69,"end_line":95,"end_character":75},"updated":"2018-12-03 20:41:28.000000000","message":"Prefer like \"score same-cell hosts at an incredibly high level\", or just a normal weigher that has a configurable multiplier?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  .. note:: A new ``CrossCellWeigher`` will be introduced which will prefer"},{"line_number":96,"context_line":"      hosts from the source cell. Since a cross-cell resize is more"},{"line_number":97,"context_line":"      complicated / expensive than a normal resize, we always want to use"},{"line_number":98,"context_line":"      hosts from the source cell if possible. This weigher will be a noop"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_18b93c2d","line":95,"range":{"start_line":95,"start_character":69,"end_line":95,"end_character":75},"in_reply_to":"3f79a3b5_4e54cdc5","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":92,"context_line":"  the RequestSpec to tell the scheduler to not restrict hosts to the source"},{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  .. note:: A new ``CrossCellWeigher`` will be introduced which will prefer"},{"line_number":96,"context_line":"      hosts from the source cell. Since a cross-cell resize is more"},{"line_number":97,"context_line":"      complicated / expensive than a normal resize, we always want to use"},{"line_number":98,"context_line":"      hosts from the source cell if possible. This weigher will be a noop"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_4e54cdc5","line":95,"range":{"start_line":95,"start_character":69,"end_line":95,"end_character":75},"in_reply_to":"3f79a3b5_889c1cbf","updated":"2018-12-03 22:17:31.000000000","message":"Both, but the default multiplier will be incredibly high:\n\nhttps://review.openstack.org/#/c/614353/4/nova/conf/scheduler.py","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  .. note:: A new ``CrossCellWeigher`` will be introduced which will prefer"},{"line_number":96,"context_line":"      hosts from the source cell. Since a cross-cell resize is more"},{"line_number":97,"context_line":"      complicated / expensive than a normal resize, we always want to use"},{"line_number":98,"context_line":"      hosts from the source cell if possible. This weigher will be a noop"},{"line_number":99,"context_line":"      for all non-cross-cell move operations."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_39dffc0a","line":96,"range":{"start_line":96,"start_character":6,"end_line":96,"end_character":32},"updated":"2018-12-20 10:12:55.000000000","message":"by default? maybe sometime we want to prefer cross-cell, like in the case that we want to encourage users to move to new cell so that we can get rid of the old hardwares.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  .. note:: A new ``CrossCellWeigher`` will be introduced which will prefer"},{"line_number":96,"context_line":"      hosts from the source cell. Since a cross-cell resize is more"},{"line_number":97,"context_line":"      complicated / expensive than a normal resize, we always want to use"},{"line_number":98,"context_line":"      hosts from the source cell if possible. This weigher will be a noop"},{"line_number":99,"context_line":"      for all non-cross-cell move operations."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_b52a212b","line":96,"range":{"start_line":96,"start_character":6,"end_line":96,"end_character":32},"in_reply_to":"3f79a3b5_39dffc0a","updated":"2018-12-20 20:39:00.000000000","message":"Yes by default, as cross-cell is more expensive than normal resize within the same cell. The point of having a configurable weigher though is you can tailor that behavior as you see fit. That might also work nicely with your per-aggregate weigher blueprint so if you have some really old hosts in an aggregate you could change the weigher on those to make servers resize out of those hosts into a newer cell.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":93,"context_line":"  cell, but the source cell will be \"preferred\"."},{"line_number":94,"context_line":""},{"line_number":95,"context_line":"  .. note:: A new ``CrossCellWeigher`` will be introduced which will prefer"},{"line_number":96,"context_line":"      hosts from the source cell. Since a cross-cell resize is more"},{"line_number":97,"context_line":"      complicated / expensive than a normal resize, we always want to use"},{"line_number":98,"context_line":"      hosts from the source cell if possible. This weigher will be a noop"},{"line_number":99,"context_line":"      for all non-cross-cell move operations."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_38b43835","line":96,"range":{"start_line":96,"start_character":6,"end_line":96,"end_character":32},"in_reply_to":"3f79a3b5_b52a212b","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6415fd11a425893d0dd0137e72d3ef2941fe033a","unresolved":false,"context_lines":[{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* A new ``CrossCellMigrationTask`` will orchestrate the following sub-tasks:"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  * Verify the selected target host to ensure ports and volumes will work."},{"line_number":108,"context_line":"    This validation will include creating port bindings on the target host"},{"line_number":109,"context_line":"    and ensuring volume attachments can be connected to the host. If either"},{"line_number":110,"context_line":"    of these fail, the target host will be rejected. At that point, the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_649e9355","line":107,"updated":"2019-01-02 16:47:02.000000000","message":"I realize now that how I have this written in my PoC won\u0027t work because it\u0027s running code on the dest host in the dest cell but looking up things in the database related to the instance, and the instance record (and related tables) aren\u0027t created in the dest cell DB at this point, so that won\u0027t work. The functional tests pass because of how our test fixtures work (CheatingSerializer leaves the request context targeted at the source cell).\n\nSo I\u0027m going to need to create the target cell DB records early in the process.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":104,"context_line":""},{"line_number":105,"context_line":"* A new ``CrossCellMigrationTask`` will orchestrate the following sub-tasks:"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"  * Verify the selected target host to ensure ports and volumes will work."},{"line_number":108,"context_line":"    This validation will include creating port bindings on the target host"},{"line_number":109,"context_line":"    and ensuring volume attachments can be connected to the host. If either"},{"line_number":110,"context_line":"    of these fail, the target host will be rejected. At that point, the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_b21d00bf","line":107,"in_reply_to":"1f769fc5_649e9355","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":115,"context_line":"    be used throughout the rest of the resize and during the confirm/revert"},{"line_number":116,"context_line":"    flows."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"  * Shelve offload from the source cell. The migration object will be passed"},{"line_number":119,"context_line":"    to the ``shelve_offload_instance`` method in the compute service to"},{"line_number":120,"context_line":"    control how the shelve behaves regarding things like removing allocations"},{"line_number":121,"context_line":"    in placement (we will retain these migration-based allocations on the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c8e0d430","line":118,"range":{"start_line":118,"start_character":45,"end_line":118,"end_character":76},"updated":"2018-12-03 20:41:28.000000000","message":"Note this is a tad weird in that shelve will receive a migration object saying it\u0027s of type \"resize\". Not sure that\u0027s a problem or what to do differently, but I\u0027m noting that it feels like it could be a source of bugs at some point.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":115,"context_line":"    be used throughout the rest of the resize and during the confirm/revert"},{"line_number":116,"context_line":"    flows."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"  * Shelve offload from the source cell. The migration object will be passed"},{"line_number":119,"context_line":"    to the ``shelve_offload_instance`` method in the compute service to"},{"line_number":120,"context_line":"    control how the shelve behaves regarding things like removing allocations"},{"line_number":121,"context_line":"    in placement (we will retain these migration-based allocations on the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_9220fcf9","line":118,"range":{"start_line":118,"start_character":45,"end_line":118,"end_character":76},"in_reply_to":"3f79a3b5_ae1241fd","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":115,"context_line":"    be used throughout the rest of the resize and during the confirm/revert"},{"line_number":116,"context_line":"    flows."},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"  * Shelve offload from the source cell. The migration object will be passed"},{"line_number":119,"context_line":"    to the ``shelve_offload_instance`` method in the compute service to"},{"line_number":120,"context_line":"    control how the shelve behaves regarding things like removing allocations"},{"line_number":121,"context_line":"    in placement (we will retain these migration-based allocations on the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_ae1241fd","line":118,"range":{"start_line":118,"start_character":45,"end_line":118,"end_character":76},"in_reply_to":"3f79a3b5_c8e0d430","updated":"2018-12-03 22:17:31.000000000","message":"The alternative I\u0027ve kicked around in my head is the orchestration task in conductor would create a MigrationContext and stash that on the instance, so that from within shelve/unshelve etc we can interrogate the instance to determine if we\u0027re doing a migration rather than explicitly pass the migration object. Right now I\u0027ve mostly not had to deal with migration context at all - and that\u0027s also the first open question below, do I need to worry about a migration context? The nice thing about just passing the migration object around is it\u0027s very explicit. I tend to get lost in tracking the migration context during a normal resize since it\u0027s tickled in several places in compute, API and RT.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":123,"context_line":""},{"line_number":124,"context_line":"  * The conductor task will poll the status of the instance in the source cell"},{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_9a9ddfba","line":127,"range":{"start_line":126,"start_character":20,"end_line":127,"end_character":57},"updated":"2018-12-20 10:12:55.000000000","message":"so user will not be able to cross-cell resize if they don\u0027t have more image quota","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":123,"context_line":""},{"line_number":124,"context_line":"  * The conductor task will poll the status of the instance in the source cell"},{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_f2238804","line":127,"range":{"start_line":126,"start_character":20,"end_line":127,"end_character":57},"in_reply_to":"3f79a3b5_75d56918","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":123,"context_line":""},{"line_number":124,"context_line":"  * The conductor task will poll the status of the instance in the source cell"},{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_75d56918","line":127,"range":{"start_line":126,"start_character":20,"end_line":127,"end_character":57},"in_reply_to":"3f79a3b5_9a9ddfba","updated":"2018-12-20 20:39:00.000000000","message":"Correct, but I\u0027m not sure how often that is a problem for anyone. Also, with normal shelve/unshelve, nova automatically deletes the snapshot when you unshelve:\n\nhttps://github.com/openstack/nova/blob/a1c01f97ae0397e8f4ccff5eb2a8b8f5ef7f7221/nova/compute/manager.py#L5066\n\nor delete the server:\n\nhttps://github.com/openstack/nova/blob/a1c01f97ae0397e8f4ccff5eb2a8b8f5ef7f7221/nova/compute/api.py#L1945","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_08decc6a","line":128,"updated":"2018-12-03 20:41:28.000000000","message":"Okay, so if the conductor that is polling this gets restarted before this process is over, what is the recovery? Presumably the instance will go into SHELVED_OFFLOADED state and then a normal unshelve by the user can restart this to at least go back to the original cell or something?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2ede310f","line":128,"in_reply_to":"3f79a3b5_08decc6a","updated":"2018-12-03 22:17:31.000000000","message":"\u003e Presumably the instance will go into SHELVED_OFFLOADED state\n\nIf you\u0027re doing a single conductor and you restart it at the same time that nova-compute is trying to update the status to SHELVED_OFFLOADED, that may fail, right? In which case we get a fault on the instance (if we can even create the fault record because again, we need to go through conductor to get to the DB).\n\nIf the instance does go to SHELVE_OFFLOADED status, it will still be in the source cell and I think unshelving it would work. The way the task is written, we don\u0027t create the records in the target cell db until we\u0027ve shelved offloaded from the source:\n\nhttps://review.openstack.org/#/c/603930/17/nova/conductor/tasks/cross_cell_migrate.py@416\n\nAnd the instance mapping would still be OK also. The things we\u0027d probably have orphaned are volume attachments, port bindings and any allocations created against the target compute node resource provider via the scheduler, so we\u0027d probably need to investigate that; I don\u0027t think RT._remove_deleted_instances_allocations would clean those up for the target host because I think we\u0027d get here:\n\nhttps://github.com/openstack/nova/blob/1e8c2c0dcb3ff9225407b890a6c99658b35764bc/nova/compute/resource_tracker.py#L1287","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5cebd10e","line":128,"in_reply_to":"3f79a3b5_2ede310f","updated":"2018-12-20 00:10:11.000000000","message":"To summarize, IIUC, if the polling is interrupted or times out, the instance will go into SHELVED_OFFLOADED and remain in the source cell, and the user can recover by issuing an \u0027unshelve\u0027 request.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_b510e1ab","line":128,"in_reply_to":"3f79a3b5_5422bd0f","updated":"2018-12-20 20:39:00.000000000","message":"My main concern was with the terminal states, so ACTIVE -\u003e VERIFY_RESIZE -\u003e (confirm/revert). I care less about the intermediate states based on the task_state. Same goes for the instance action events and notifications since I\u0027m not really sure how those are consumed beyond the terminal state (task_state\u003dNone).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5422bd0f","line":128,"in_reply_to":"3f79a3b5_5cebd10e","updated":"2018-12-20 10:12:55.000000000","message":"Do we really want the states change to \"shelve_offloaded\"? I mean, for single-cell migration, we won\u0027t have this state in state transactions, should we keep the same, or this will be added since the cross-cell is special? maybe the notification and event record could be messed up for outside monitoring services?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d5e6bddc","line":128,"in_reply_to":"3f79a3b5_5cebd10e","updated":"2018-12-20 20:39:00.000000000","message":"Yes I think so. What we\u0027d do if we timeout is a bit unclear. I mean at a minimum we\u0027d probably record a fault and send an event, but I\u0027m not sure you\u0027d want to put the instance in ERROR status or something, especially if the compute eventually does complete and changes the status to SHELVED_OFFLOADED.\n\nLooking at https://review.openstack.org/#/c/603930/19/nova/compute/manager.py@4962 again though, I\u0027ve got a TODO in the shelve offload code such that we don\u0027t end in a terminal state (vm_state is SHELVED_OFFLOADED and task_state is None) while we\u0027re doing the cross-cell resize - we should at least leave the task_state set so a user can\u0027t do something on the instance while we\u0027re undergoing the cross-cell resize. If we do that though, and polling times out or is interrupted, the instance would be stuck in some transition state and the admin would have to reset the state (which either goes to ACTIVE or ERROR in the API, neither of which is what we\u0027d want if the instance is really shelved offloaded):\n\nhttps://developer.openstack.org/api-ref/compute/?expanded\u003dreset-server-state-os-resetstate-action-detail#reset-server-state-os-resetstate-action\n\nWe could add \"shelved_offloaded\" to that list as part of this blueprint, but that seems pretty hacky.\n\nIf the server was offloaded and the admin reset the state to ERROR, then rebuilding it won\u0027t help because rebuild relies on rebuilding to the host the instance is on, and if the server is offloaded there is no host...unless we hack rebuild to trigger an unshelve in this case...it gets pretty gorpy.\n\nHaving said all this, I\u0027m not sure we have great forethought in recovery actions for most of the move operations we support today. I\u0027m not sure what operators do in the case of failed evacuations, or live migrations. I suspect there is probably quite a bit of DB surgery that happens. So I\u0027d like to be as resilient as possible, but I\u0027m not sure how far it goes.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":125,"context_line":"    database until the shelve offload operation is complete or a configurable"},{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_d2268417","line":128,"in_reply_to":"3f79a3b5_d5e6bddc","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"  * Update the instance mapping to point at the target cell. We do this"},{"line_number":133,"context_line":"    before unshelving on the target host in order to properly route neutron"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_745ed978","line":130,"range":{"start_line":129,"start_character":67,"end_line":130,"end_character":14},"updated":"2018-12-20 10:12:55.000000000","message":"Do we copy the whole history records? I mean, if we don\u0027t, we will not be able to check history records for actions, migrations, events etc for a cross-cell resized instance.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"  * Update the instance mapping to point at the target cell. We do this"},{"line_number":133,"context_line":"    before unshelving on the target host in order to properly route neutron"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_757b29f1","line":130,"range":{"start_line":129,"start_character":67,"end_line":130,"end_character":14},"in_reply_to":"3f79a3b5_745ed978","updated":"2018-12-20 20:39:00.000000000","message":"Yes we copy the entire history of (non-deleted) records:\n\nhttps://review.openstack.org/#/c/603930/19/nova/conductor/tasks/cross_cell_migrate.py@227","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":126,"context_line":"    timeout occurs. As a result of a successful offload of an image-backed"},{"line_number":127,"context_line":"    server, a snapshot image will be available in glance."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"  * Create the instance and its related records (BDMs, VIFs, tags, actions,"},{"line_number":130,"context_line":"    migrations, etc) in the target cell database."},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"  * Update the instance mapping to point at the target cell. We do this"},{"line_number":133,"context_line":"    before unshelving on the target host in order to properly route neutron"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_321270b3","line":130,"range":{"start_line":129,"start_character":67,"end_line":130,"end_character":14},"in_reply_to":"3f79a3b5_757b29f1","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":140,"context_line":"    terminal ``vm_state`` on the instance (``resized`` rather than ``active``)."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"  * The conductor task will poll the status of the instance in the target cell"},{"line_number":143,"context_line":"    database until it is resized or a configurable timeout occurs."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Confirm flow"},{"line_number":146,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_48428410","line":143,"updated":"2018-12-03 20:41:28.000000000","message":"To what end? Does it do something to it once it completes, or do something else if it times out? Also, the configurable timeout, while important, is likely to be long in the case of moving to a completely different cell where a very large custom snapshot has to be downloaded, potentially from a place that hasn\u0027t cached it local to the new cell. Will this be specific to this situation, i.e. something like instance_unshelve_from_other_cell_timeout ?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":140,"context_line":"    terminal ``vm_state`` on the instance (``resized`` rather than ``active``)."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"  * The conductor task will poll the status of the instance in the target cell"},{"line_number":143,"context_line":"    database until it is resized or a configurable timeout occurs."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Confirm flow"},{"line_number":146,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6e22e910","line":143,"in_reply_to":"3f79a3b5_48428410","updated":"2018-12-03 22:17:31.000000000","message":"\u003e Does it do something to it once it completes, or do something else if it times out?\n\nYes, right now the instance mapping is updated *after* we\u0027ve successfully unshelved in the target cell:\n\nhttps://review.openstack.org/#/c/603930/17/nova/conductor/tasks/cross_cell_migrate.py@428\n\nHowever, see my FIXME above that:\n\nhttps://review.openstack.org/#/c/603930/17/nova/conductor/tasks/cross_cell_migrate.py@417\n\nGiven that FIXME, I\u0027m inclined to update the instance mapping *before* we unshelve so the API can properly route the network-vif-plugged event (I think that has to happen, regardless of my comment about migration_context there).\n\n\u003e Will this be specific to this situation, i.e. something like instance_unshelve_from_other_cell_timeout ?\n\nYup: https://review.openstack.org/#/c/603930/17/nova/conf/conductor.py","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":140,"context_line":"    terminal ``vm_state`` on the instance (``resized`` rather than ``active``)."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":"  * The conductor task will poll the status of the instance in the target cell"},{"line_number":143,"context_line":"    database until it is resized or a configurable timeout occurs."},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Confirm flow"},{"line_number":146,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_120dec8f","line":143,"in_reply_to":"3f79a3b5_6e22e910","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_88517cd8","line":156,"updated":"2018-12-03 20:41:28.000000000","message":"Remind me how we\u0027re going to avoid instances that are waiting for confirmation from showing up in a list?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_7218f8d2","line":156,"in_reply_to":"1f769fc5_07e561a8","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"68e283ec14c689d9e8acec3e7194ad7fdbdf877e","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_07e561a8","line":156,"in_reply_to":"1f769fc5_278dfd7a","updated":"2019-01-02 18:32:00.000000000","message":"\u003e This is why I kinda think we should have some deterministic way to know if the instance in the other cell is important to be shown or not. That could be the deleted flag, a special instance state, or some other flag. That way we can just explicitly filter that out at the API or DB layer.\n\nI agree we need something deterministic. I think having the instance record marked as deleted during certain phases is likely going to have weird side effects, e.g. the various \"Instance.deleted \u003d\u003d 0\" filters in the DB models. Also, if the admin lists deleted instances, they\u0027d still have the duplicate listing problem. So I am leaning toward some special state or flag that we can filter on, maybe even just a simple \u0027hidden\u0027 field on the Instance record (note there is a migrations.hidden column but it\u0027s not used for anything).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_ae4a4122","line":156,"in_reply_to":"3f79a3b5_260e5f30","updated":"2018-12-14 21:51:02.000000000","message":"Yeah I\u0027ve got a recreate in my functional test with a FIXME on it so we don\u0027t forget about it. For the migration listing I\u0027m filtering on updated_at (since migration list doesn\u0027t have user-provided sort keys) and returning the most recent updated_at migration record.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_8e5c2580","line":156,"in_reply_to":"3f79a3b5_88517cd8","updated":"2018-12-03 22:17:31.000000000","message":"My functional test has an assertion for this and for whatever reason it\u0027s not an issue right now:\n\nhttps://review.openstack.org/#/c/603930/17/nova/tests/functional/test_cross_cell_migrate.py@141\n\nIt was an issue I hit for listing migration records though:\n\nhttps://review.openstack.org/#/c/603930/17/nova/compute/api.py@4771\n\nI think you and I talked about the instance listing thing in Berlin and you had an idea that the reason I\u0027m getting one result back is because the view builder is keying off instance UUID and as a result, I\u0027m just getting the last one processed instead of duplicates.\n\nI\u0027ll put a comment in my functional test that I need to figure out a way to tease that behavior and assert we\u0027re getting back the one we expect. It might be as simple as checking the target host is what we expect since I think the instance record in the source cell will point at the source host and the instance in the target cell will point at the target host.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ab4324cd2c8b472ad22532cbe6766fb118d3a011","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_fa537a07","line":156,"in_reply_to":"3f79a3b5_8e5c2580","updated":"2018-12-10 23:16:30.000000000","message":"OK so this is why we only get one result:\n\nhttps://github.com/openstack/nova/blob/08d617084e5aa69ada0898d674022621d130aef3/nova/compute/api.py#L2684\n\nThe problem is we\u0027re getting lucky and it might not be the one we really want, e.g. after the instance is resized onto the target host in the target cell, we could get the shelved offloaded instance from the source cell which doesn\u0027t have a host set (and has the wrong status). Definitely something that needs to be fixed - just not sure how. Maybe if the task_state is set we filter it out?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_bd9e9ff8","line":156,"in_reply_to":"3f79a3b5_ae4a4122","updated":"2018-12-20 00:10:11.000000000","message":"TL;DR for anyone reading this, this is about an instance awaiting resize confirmation, the instance will exist in two cells technically (source and destination) and in an instance list, we only want to show one instance for that UUID.\n\nAm I missing something or could we just do a de-dupe of instance UUID (assuming the UUID is same in both source and dest cell) and prefer the one that is not vm_states.SHELVED_OFFLOADED? Or is that the \"subversive hiding\" that you (Dan) think could be a problem? Do we really want to ever be returning two instances with the same UUID out of the cross-cell instance lister?\n\nThe root of this problem is that we\u0027ll be intentionally duping an instance because we\u0027re leveraging shelve to do the migration. That\u0027s most of why it feels like shelve isn\u0027t as great of a fit here, IMHO (see later comment on shelve, in general). If we didn\u0027t use shelve, we would delete the source instance record right away when the instance goes to VERIFY_RESIZE and write it back to the source in the event of a revert, unless I\u0027m missing something.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5a0cf3e568685a75308cdc67fe8c789cb48f6f8e","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_278dfd7a","line":156,"in_reply_to":"3f79a3b5_bd9e9ff8","updated":"2019-01-02 17:32:09.000000000","message":"\u003e Am I missing something or could we just do a de-dupe of instance\n \u003e UUID (assuming the UUID is same in both source and dest cell) and\n \u003e prefer the one that is not vm_states.SHELVED_OFFLOADED? Or is that\n \u003e the \"subversive hiding\" that you (Dan) think could be a problem? Do\n \u003e we really want to ever be returning two instances with the same\n \u003e UUID out of the cross-cell instance lister?\n\nYes, that\u0027s what I mean: hiding instances that are in special states.\n\nWe can\u0027t really de-dupe in the cross-cell lister without some very specific information because we don\u0027t know which one we\u0027ll get to first, so we don\u0027t know if we should hide it or show it. We could walk all the results to de-dupe them, but that would un-do a lot of the work the cross-cell stuff does to *not* iterate the results. Right now, Matt\u0027s tests work because he\u0027s getting lucky and the dedupe-instances-and-build-requests thing is removing the first (or the last, or whatever) result, but we can\u0027t really depend on that obviously.\n\nThis is why I kinda think we should have some deterministic way to know if the instance in the other cell is important to be shown or not. That could be the deleted flag, a special instance state, or some other flag. That way we can just explicitly filter that out at the API or DB layer.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5592adfb","line":156,"in_reply_to":"3f79a3b5_bd9e9ff8","updated":"2018-12-20 20:39:00.000000000","message":"\u003e The root of this problem is that we\u0027ll be intentionally duping an instance because we\u0027re leveraging shelve to do the migration. That\u0027s most of why it feels like shelve isn\u0027t as great of a fit here, IMHO (see later comment on shelve, in general). If we didn\u0027t use shelve, we would delete the source instance record right away when the instance goes to VERIFY_RESIZE and write it back to the source in the event of a revert, unless I\u0027m missing something.\n\nThis doesn\u0027t really have anything to do with whether or not we use shelve. As long as the instance is in both databases, we have to hide duplicates when listing servers. With the way I\u0027ve written the PoC, the instance is in both databases until the resize is either confirmed or reverted (again, the underlying mechanics of what happens with the server in the compute service could be shelve / unshelve or something completely new).\n\nEven if we deleted the record from the source cell as soon as the instance is in VERIFY_RESIZE state in the target cell, you still have a period of time where the instance is in both databases (between the time you snapshot from the source cell and create the new record in the target cell and spawn (unshelve) the instance in the target cell).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":153,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":154,"context_line":"is True, the API will:"},{"line_number":155,"context_line":""},{"line_number":156,"context_line":"* Delete the instance and its related records from the source cell database."},{"line_number":157,"context_line":""},{"line_number":158,"context_line":"* Update the ``Migration.status`` to ``confirmed`` (normally the"},{"line_number":159,"context_line":"  ``confirm_resize`` method on the source compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_260e5f30","line":156,"in_reply_to":"3f79a3b5_fa537a07","updated":"2018-12-14 16:44:37.000000000","message":"Maybe, although that starts getting a little hairy if we\u0027ve got subversive hiding of specific instances right there. I don\u0027t have a much better idea off the top of my head, but it\u0027s obviously an open issue.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":176,"context_line":"RPC cast to a new conductor method ``revert_cross_cell_resize`` which will"},{"line_number":177,"context_line":"execute a new ``CrossCellRevertResizeTask``. That task will:"},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* Shelve offload the instance from the target cell and poll the target cell"},{"line_number":180,"context_line":"  database until the instance is offloaded or a configurable timeout occurs."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"  .. note:: In this case we do not want the shelve operation to create a new"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_08656cb0","line":179,"range":{"start_line":179,"start_character":2,"end_line":179,"end_character":50},"updated":"2018-12-03 20:41:28.000000000","message":"Remind me why we don\u0027t just delete it?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":176,"context_line":"RPC cast to a new conductor method ``revert_cross_cell_resize`` which will"},{"line_number":177,"context_line":"execute a new ``CrossCellRevertResizeTask``. That task will:"},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* Shelve offload the instance from the target cell and poll the target cell"},{"line_number":180,"context_line":"  database until the instance is offloaded or a configurable timeout occurs."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"  .. note:: In this case we do not want the shelve operation to create a new"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2e9631f0","line":179,"range":{"start_line":179,"start_character":2,"end_line":179,"end_character":50},"in_reply_to":"3f79a3b5_08656cb0","updated":"2018-12-03 22:17:31.000000000","message":"Because without a bunch of changes to the ComputeManager.terminate_instance code we\u0027d end up detaching/deleting ports and volumes attached to the instance. I know we talked about this in IRC and I thought I had documented the results of that with a comment in my change, but now I\u0027m not seeing it, but that was the issue.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":176,"context_line":"RPC cast to a new conductor method ``revert_cross_cell_resize`` which will"},{"line_number":177,"context_line":"execute a new ``CrossCellRevertResizeTask``. That task will:"},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* Shelve offload the instance from the target cell and poll the target cell"},{"line_number":180,"context_line":"  database until the instance is offloaded or a configurable timeout occurs."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"  .. note:: In this case we do not want the shelve operation to create a new"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_521374b9","line":179,"range":{"start_line":179,"start_character":2,"end_line":179,"end_character":50},"in_reply_to":"3f79a3b5_0e133505","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":176,"context_line":"RPC cast to a new conductor method ``revert_cross_cell_resize`` which will"},{"line_number":177,"context_line":"execute a new ``CrossCellRevertResizeTask``. That task will:"},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* Shelve offload the instance from the target cell and poll the target cell"},{"line_number":180,"context_line":"  database until the instance is offloaded or a configurable timeout occurs."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"  .. note:: In this case we do not want the shelve operation to create a new"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_0e133505","line":179,"range":{"start_line":179,"start_character":2,"end_line":179,"end_character":50},"in_reply_to":"3f79a3b5_26273fb2","updated":"2018-12-14 21:51:02.000000000","message":"Local delete (in the API) will also detach volumes and ports which isn\u0027t what we want. And local delete doesn\u0027t do anything on the compute and we need to destroy the guest otherwise we\u0027ll orphan it in the hypervisor where it will continue to consume resources that we aren\u0027t tracking.\n\nShelve offload on revert is nice since it covers both of those issues - it kills the guest in the target cell, frees up the resources we\u0027re tracking, but maintains the volume/port attachments.\n\nFor the revert flow, we\u0027re not doing another snapshot to glance from the target because as you correctly noted, we could have resized the disk up and then reverting back from that larger snapshot could fail on the source with the old flavor. So on revert, the idea is just shelve offload (but no snapshot) from target to cleanup the target, then unshelve on the source using the original image (not the snapshot from the first shelve when going from source-\u003etarget). The tricky thing is keeping a handle to the original image_ref so we can unshelve from it on revert - likely something that gets stashed in the instance system_metadata with the other shelve keys (and/or we track that in the migration context if I start using that to squirrel stuff away).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":176,"context_line":"RPC cast to a new conductor method ``revert_cross_cell_resize`` which will"},{"line_number":177,"context_line":"execute a new ``CrossCellRevertResizeTask``. That task will:"},{"line_number":178,"context_line":""},{"line_number":179,"context_line":"* Shelve offload the instance from the target cell and poll the target cell"},{"line_number":180,"context_line":"  database until the instance is offloaded or a configurable timeout occurs."},{"line_number":181,"context_line":""},{"line_number":182,"context_line":"  .. note:: In this case we do not want the shelve operation to create a new"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_26273fb2","line":179,"range":{"start_line":179,"start_character":2,"end_line":179,"end_character":50},"in_reply_to":"3f79a3b5_2e9631f0","updated":"2018-12-14 16:44:37.000000000","message":"And we couldn\u0027t re-use the local delete code path to replicate that? I know local delete is not the shining beacon of amazingness, but...\n\nIt seems like it would be worthwhile to not have to do the unshelve, as that would have copied the whole instance to glance from the source, then copied it all back just so we can run a cleanup routine. Maybe not critical for v1,  but we should probably try to do better.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_bae0db2e","line":193,"range":{"start_line":193,"start_character":36,"end_line":193,"end_character":47},"updated":"2018-12-20 10:12:55.000000000","message":"only the source cell? how about all cells available for the flavor but prefer source cell?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_b24420b9","line":193,"range":{"start_line":193,"start_character":36,"end_line":193,"end_character":47},"in_reply_to":"3f79a3b5_151c357a","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_151c357a","line":193,"range":{"start_line":193,"start_character":36,"end_line":193,"end_character":47},"in_reply_to":"3f79a3b5_bae0db2e","updated":"2018-12-20 20:39:00.000000000","message":"I suppose we could do that. I mean, that essentially is an unshelve operation at a cell level (unshelve picks any host that fits the server, it doesn\u0027t have to be the one it was shelved offloaded from).\n\nI think it probably depends on what we do with deleting the source cell records and resource allocations. Today the source cell record and source host allocations are not cleaned up until confirm/revert since they are basically serving as a placeholder in case you revert.\n\nIf we change that such that we ditch everything we had in the source cell (the data, the allocations, all of it), then it\u0027s really more like a shelve offload operation at a cell level since you\u0027ve completely offloaded out of the source cell. In that case, on revert, we\u0027re just asking the scheduler for a new host in whatever cell (might not be the target) and you\u0027re doing the same cross-cell resize but with the old flavor all over again. It might work, but it\u0027s more complicated and I think it\u0027s also pretty risky, at least in the initial version of this feature. I tend to want to be able to get back \"home\" where we knew things worked before the resize in the case of (1) revert or (2) something blew up along the way and the operator is trying to recover.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_28f5c8c9","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"updated":"2018-12-03 20:41:28.000000000","message":"Wait, so if the migration is holding the spot on the source host, why would we need to handle the original source being unavailable? Shouldn\u0027t we just check that it\u0027s up and do a revert-like operation on it to convert the migration allocation back to a real one? With a regular resize, you can\u0027t abort if your source host has since gone away right? I don\u0027t see any reason to do the schedule thing differently here -- what amI missing?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d4d0f669549e7da5cf8f94c798dcdebb0d0d05f8","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_ed187e76","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"1f769fc5_c78f6921","updated":"2019-01-03 14:41:47.000000000","message":"\u003e \"Conductor-coordinated resize\" also rings a bell when I think back\n \u003e to the Yahoo/Oath environment where they\u0027ve had to disable resize\n \u003e because it requires ssh access between compute hosts. Years ago, I\n \u003e remember design summit discussions about it where conductor-coordinated\n \u003e resize was mentioned as a possible future solution for deployers\n \u003e with restrictions on compute host isolation.\n \nWell, to be clear, what I meant by \"conductor coordinated\" was that we\u0027d still ask the computes to transfer the image if they were able to speak to each other, which is why I said we would have an \"okay now you move the image\" call. Funneling the data through a random conductor, especially a superconductor does not seem reasonable to me, but taking this approach _would_ enable people with those kinds of restrictions to just always use the snapshot approach to move things around, even within a cell if they prefer that performance pain over the security issues.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_92479cbd","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"1f769fc5_c78f6921","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"91beccaeb83c73a32a8a046bd07ef103cdd83084","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_c78f6921","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"1f769fc5_c7d2095d","updated":"2019-01-02 17:51:15.000000000","message":"\"Conductor-coordinated resize\" also rings a bell when I think back to the Yahoo/Oath environment where they\u0027ve had to disable resize because it requires ssh access between compute hosts. Years ago, I remember design summit discussions about it where conductor-coordinated resize was mentioned as a possible future solution for deployers with restrictions on compute host isolation.\n\nI\u0027m not using this as an argument for conductor-coordinated resize, but wanted to mention it as another potential benefit (if \"move image\" behavior would be configurable).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_26aadfcf","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_054a9c23","updated":"2018-12-14 16:44:37.000000000","message":"Ugh, this is all kinda icky and makes me wonder if shelve is the right thing to do here. Could we save some of this trouble by not actually offloading the instance? If we don\u0027t care about the instance.host\u003dNone part since we\u0027re moving to another cell, then I\u0027m not sure what would prevent us from starting it up in the other cell without it being offloaded...\n\nAlso, since the user can\u0027t depend on having a confirm/revert step (since that depends on operator config), I guess we could also just eliminate the possibility of a revert for cross-cell migrations from the first version...","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"932c28bae508e35a76f6515c1d7dbe3d326beaf8","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_b1f860c2","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_0e86d51a","updated":"2018-12-14 22:14:43.000000000","message":"I meant using shelve at all. Just the more that I think about it. Less of it applies than I was thinking initially. I\u0027m just lamenting the potential complexity (thinking evacuate and rebuild, where they re-use a lot of code on the surface, but we end up with spaghetti underneath). Don\u0027t change course on my account. I wish we could get some more opinions on this, but I think we likely won\u0027t. You\u0027re doing the work and I\u0027m not, so we should choose the major path according to what you think will work out the best.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_0e86d51a","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_26aadfcf","updated":"2018-12-14 21:51:02.000000000","message":"\u003e Ugh, this is all kinda icky and makes me wonder if shelve is the right thing to do here.\n\nDo you mean in general for the entire cross-cell resize flow, or just the revert part? The revert is definitely the more complicated thing.\n\nI haven\u0027t put a ton of thought into not using shelve/unshelve for this, but have thought about it at least a bit. Obviously there would be a lot of redundant code though probably, but at least it would be single-purpose and less hacky, i.e. no \"are we doing a cross-cell resize thing or normal shelve/unshelve\" logic. We might be able to better orchestrate that from conductor as well, but again, I haven\u0027t put much thought into it. Maybe it would be as simple (tm) as:\n\n1. snapshot from source cell\n2. detach ports/volumes from source host but keep them logically reserved in the DB (like shelve does)\n3. build (spawn) from snapshot with new flavor in target cell\n\nThen on confirm, we destroy the instance in the source cell (including the guest in the hypervisor - might need a new compute service method for that so we don\u0027t lose ports/volumes).\n\nOn revert, we destroy from the target (same as confirm, saving ports/volumes) and just flip the DB states at the top to point back at the instance in the source cell.\n\nWhat would the issues be there?\n\n- resource usage would be double counted for the consumer while resized (but I think we already have that problem today)\n\n- the guest would be running in two places which could be bad (security?); maybe alleviated if we stop the guest on the source before spawning it on the target\n\n--\n\nAnyway, it would be a re-write at this point so I\u0027d want to be pretty serious about it before starting to crank out code.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_4e0e0d3d","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_28f5c8c9","updated":"2018-12-03 22:17:31.000000000","message":"I had that thought also:\n\nhttps://review.openstack.org/#/c/603930/17/nova/conductor/tasks/cross_cell_migrate.py@838\n\nAs you can see in that comment, I\u0027ve gone back and forth on this a bit. Part of it is wanting to sanity check the source host, via the scheduler, that it will still work for the instance during unshelve (revert). I could have also just been thinking about the scheduler because that\u0027s how unshelve works today, and the orchestration in the new conductor task leans heavily on doing things with existing code as much as possible - even though we\u0027re not calling the conductor unshelve RPC API at all in here.\n\nBypassing the scheduler on revert would mean dropping a lot of this complexity:\n\nhttps://review.openstack.org/#/c/603930/17/nova/conductor/tasks/cross_cell_migrate.py@544\n\nI was also trying to go for a kind of reschedule to alternate in the case that the source host is no longer available, since with unshelve we can really pick any host in the source cell that fits the request spec, it doesn\u0027t have to be the original one.\n\nIn the interest of keeping this as simple as possible, we could just bypass the scheduler in the initial version and add a comment about potentially wanting to robustify that later if we need to bake in reschedule logic.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"c949550ea2a94135e3ba01a6a86889fd7a50079c","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_054a9c23","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_4e0e0d3d","updated":"2018-12-10 21:51:32.000000000","message":"One other thing with bypassing the scheduler on revert and simply unshelving directly on the original source host is that we still have to pass down \"limits\" for things like PCI/NUMA resources for the old style claims on those resources. I *think* the original limits might still be in the RequestSpec:\n\nhttps://github.com/openstack/nova/blob/08d617084e5aa69ada0898d674022621d130aef3/nova/objects/request_spec.py#L79\n\nBut I\u0027m not at all confident that we ever update that to whatever the last-used flavor was, e.g. let\u0027s say you create a server with flavor0 and we set the reqspec.limits and persist them, then resize to flavor1, will we update the limits and persist them? Similarly, if we do resize to flavor1 and persist the limits, but revert the resize back to flavor0, do we reset the request spec limits back to flavor0 limits? I know we revert the flavor in the request spec back to the old flavor:\n\nhttps://github.com/openstack/nova/blob/08d617084e5aa69ada0898d674022621d130aef3/nova/compute/api.py#L3489\n\nBut not the limits. So RequestSpec.limits probably can\u0027t be trusted. Honestly we should probably not even persist those...","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_704fb767","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_4f1f925c","updated":"2018-12-20 20:39:00.000000000","message":"Regardless of if shelve is used at all in the compute layer, I think a lot of the orchestration bits will remain mostly unchanged in conductor/API, so that can be salvaged from the PoC (and the spec). I need to break a lot of that code apart yet anyway (separate the compute changes from the conductor and API changes).\n\nThen we\u0027re probably looking at brand new compute methods which are all about resize but are mostly redundant with the shelve/unshelve flow, e.g. we have to make RT claims on the dest host and spawn there, same as unshelve. We still have to snapshot the server from the source cell (but conductor could do this rather than the compute). The pre-validation stuff could be more baked into new compute methods, etc. I\u0027m definitely not against the idea as it would mean I don\u0027t have conditional logic and we don\u0027t need to worry about shelve events and notifications happening during a resize flow.\n\nI\u0027ll just need to spend some time cranking on it to see where it goes and ferret out issues (which is what the PoC led me to here).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_4f1f925c","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_51ab0c6f","updated":"2018-12-20 00:10:11.000000000","message":"I have to say I share the feeling that using shelve for this as being not as great a fit as we would like, and the complexity will result in all sorts of issues. But, the PoC has been up forever and I didn\u0027t review it, and you did all the work, so I am OK with going forward with what you have for v1. And it\u0027s difficult to predict which way would be less messy, as you point out.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5a0cf3e568685a75308cdc67fe8c789cb48f6f8e","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_c7d2095d","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_704fb767","updated":"2019-01-02 17:32:09.000000000","message":"Building new resize methods that involve conductor orchestrating more of the process would have some benefits you know. It would help for cross-cell-resize, but also potentially de-clutter a lot of the cruft and confusion we have in those routines. I think a conductor-coordinated resize would work universally, regardless of whether or not the two computes involved were in the same cell. You could easily have a \"okay now move the image\" call, which you conditionally call if you decide they can talk to each other, and if not, you snapshot or whatever.\n\nI know it\u0027s more work and it\u0027s easy for me to just say so, but...might be worth thinking about, even if just for a target of the next step.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4fec2f2d82933ecefc7c39a457e4d89aee35bee9","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_51ab0c6f","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"3f79a3b5_b1f860c2","updated":"2018-12-14 22:28:54.000000000","message":"Doing a PoC without shelve flows is probably worth it to sniff it out both ways. For all I know, we might be able to leverage the existing confirm/revert compute methods if we\u0027re not doing the shelve/unshelve stuff and just have to orchestrate some of the snapshot stuff from the top. Even if we did that though (trying to re-use existing confirm/revert resize compute code) I\u0027d probably fall into the same conditional logic trap, e.g. don\u0027t try to rpc cast between computes b/c those computes will be in different cells.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"8f86afa6d664881f69a191154fceabc32c0ddf41","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_0eacbc8a","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"ffd0ebdf_759f5b50","updated":"2019-01-04 21:45:21.000000000","message":"\u003e OK, I wasn\u0027t realizing that the old design summit discussion was\n \u003e talking about doing something very different (funneling data\n \u003e through conductor -- it\u0027s hard for me to remember now). But what\n \u003e you said earlier about the \"now move the image\" call made me think,\n \u003e if that behavior were configurable (scp vs snapshot), it could have\n \u003e a side benefit of enabling the use of resize for people with the\n \u003e aforementioned security issues. Which is what you just said. But\n \u003e yeah, now I see it would incur a big performance hit and is much\n \u003e different than the conductor-orchestrated resize that was discussed\n \u003e years ago.\n\nFWIW I also remember around the time of the newton midcycle meetup that Mirantis was going to investigate a bit about how to do more orchestration of some migration operations (live and cold) in conductor rather than rely on the RPC back and forth that we do, but that got bogged down a bit in documenting and then defining a state machine, sort of like what Laski wanted to do with a tasks API all those years. That\u0027s what I was thinking of when you mentioned this, and is also kind of the concept I\u0027m trying to go for (kind of have to since the computes can\u0027t RPC between each other as they are in different cells).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f06952869db5d109e09bd97f43c23e1de9c064bc","unresolved":false,"context_lines":[{"line_number":190,"context_line":"* Call the scheduler to select a host from the source cell, preferring the"},{"line_number":191,"context_line":"  original source host if it is still available. If the original source host"},{"line_number":192,"context_line":"  is no longer available, we will call the scheduler to get any available host"},{"line_number":193,"context_line":"  that fits the request spec in the source cell. Either way, the allocations"},{"line_number":194,"context_line":"  held by the migration record against the source host will be removed prior"},{"line_number":195,"context_line":"  to calling the shceduler since the scheduler will claim those resources"},{"line_number":196,"context_line":"  again."},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"* Update the instance and its related records in the source cell database"},{"line_number":199,"context_line":"  based on the contents of the target cell database. This is especially"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_759f5b50","line":196,"range":{"start_line":193,"start_character":49,"end_line":196,"end_character":8},"in_reply_to":"ffd0ebdf_ed187e76","updated":"2019-01-04 18:55:16.000000000","message":"OK, I wasn\u0027t realizing that the old design summit discussion was talking about doing something very different (funneling data through conductor -- it\u0027s hard for me to remember now). But what you said earlier about the \"now move the image\" call made me think, if that behavior were configurable (scp vs snapshot), it could have a side benefit of enabling the use of resize for people with the aforementioned security issues. Which is what you just said. But yeah, now I see it would incur a big performance hit and is much different than the conductor-orchestrated resize that was discussed years ago.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Unshelve the instance in the source cell on the selected host. The conductor"},{"line_number":216,"context_line":"  task will poll the source cell database until the instance is unshelved"},{"line_number":217,"context_line":"  (back to original active or stopped state) or a configurable timeout occurs."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"* Update the ``Migration.status`` to ``reverted`` (normally ``revert_resize``"},{"line_number":220,"context_line":"  on the destination compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a8223852","line":217,"updated":"2018-12-03 20:41:28.000000000","message":"And you will pass the migration so that unshelve can know it needs to do a convert of the migration allocations instead of a regular allocation, right?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Unshelve the instance in the source cell on the selected host. The conductor"},{"line_number":216,"context_line":"  task will poll the source cell database until the instance is unshelved"},{"line_number":217,"context_line":"  (back to original active or stopped state) or a configurable timeout occurs."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"* Update the ``Migration.status`` to ``reverted`` (normally ``revert_resize``"},{"line_number":220,"context_line":"  on the destination compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_f23aa832","line":217,"in_reply_to":"3f79a3b5_a6c58f91","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Unshelve the instance in the source cell on the selected host. The conductor"},{"line_number":216,"context_line":"  task will poll the source cell database until the instance is unshelved"},{"line_number":217,"context_line":"  (back to original active or stopped state) or a configurable timeout occurs."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"* Update the ``Migration.status`` to ``reverted`` (normally ``revert_resize``"},{"line_number":220,"context_line":"  on the destination compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_f13258f4","line":217,"in_reply_to":"3f79a3b5_a8223852","updated":"2018-12-03 22:17:31.000000000","message":"Do you mean unshelve() in the conductor or the compute? Because the new revert task doesn\u0027t use the existing conductor unshelve() method at all, it just orchestrates the calls to the computes.\n\nIn the case of unshelving back on the original source host, I\u0027m not passing the migration record:\n\nhttps://review.openstack.org/#/c/603930/17/nova/conductor/tasks/cross_cell_migrate.py@778\n\nBecause the migration record in unshelve means something specific (that we\u0027re resizing off the compute, not back to it):\n\nhttps://review.openstack.org/#/c/603930/17/nova/compute/manager.py@5120\n\nNow, depending on what happens wrt migration_context, stuff like ^ could potentially change, e.g. a migration_context could contain state about what\u0027s going on with the instance, i.e. we\u0027re resizing or we\u0027re reverting, when we unshelve.\n\nAs for cleaning up the allocations on revert, I was doing that after the successful unshelve to source and deletion of the instance et al from the target:\n\nhttps://review.openstack.org/#/c/603930/15/nova/conductor/tasks/cross_cell_migrate.py@906\n\nNote I\u0027m doubting myself in ^.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":214,"context_line":""},{"line_number":215,"context_line":"* Unshelve the instance in the source cell on the selected host. The conductor"},{"line_number":216,"context_line":"  task will poll the source cell database until the instance is unshelved"},{"line_number":217,"context_line":"  (back to original active or stopped state) or a configurable timeout occurs."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"* Update the ``Migration.status`` to ``reverted`` (normally ``revert_resize``"},{"line_number":220,"context_line":"  on the destination compute would do this)."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_a6c58f91","line":217,"in_reply_to":"3f79a3b5_f13258f4","updated":"2018-12-14 16:44:37.000000000","message":"I meant compute, to avoid unshelve doing any allocation stuff, but I think I was probably forgetting that the scheduler would have already done that for us.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":219,"context_line":"* Update the ``Migration.status`` to ``reverted`` (normally ``revert_resize``"},{"line_number":220,"context_line":"  on the destination compute would do this)."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"* Destroy the instance and its related records from the target cell database."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Limitations"},{"line_number":225,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_88d41c20","line":222,"updated":"2018-12-03 20:41:28.000000000","message":"I\u0027m a little worried that this very long process could fail in the middle and we\u0027ll end up with confusing duplicate instance records in the various databases. Could we not swap the instance mapping and delete the doomed instance at the same time, and continue to access it as necessary with read_deleted\u003dyes?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":219,"context_line":"* Update the ``Migration.status`` to ``reverted`` (normally ``revert_resize``"},{"line_number":220,"context_line":"  on the destination compute would do this)."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"* Destroy the instance and its related records from the target cell database."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Limitations"},{"line_number":225,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c6568bd1","line":222,"in_reply_to":"3f79a3b5_5178ec7b","updated":"2018-12-14 16:44:37.000000000","message":"Yeah, just limiting the amount of time where we have two copies of the thing. Deleting hard at the beginning so we don\u0027t start building the source thing until it\u0027s destined to be the one that lives would be good. That means that if we fail, a recovery step of just unshelving or whatever would be more likely to succeed I think. Anyway, it was just a thought.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":219,"context_line":"* Update the ``Migration.status`` to ``reverted`` (normally ``revert_resize``"},{"line_number":220,"context_line":"  on the destination compute would do this)."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"* Destroy the instance and its related records from the target cell database."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Limitations"},{"line_number":225,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5178ec7b","line":222,"in_reply_to":"3f79a3b5_88d41c20","updated":"2018-12-03 22:17:31.000000000","message":"Right now the instance mapping update and destroy happen right next to each other during revert, but at the end:\n\nhttps://review.openstack.org/#/c/603930/17/nova/conductor/tasks/cross_cell_migrate.py@900\n\n\u003e Could we not swap the instance mapping and delete the doomed instance at the same time, and continue to access it as necessary with read_deleted\u003dyes?\n\nI assume you mean doing that swap and delete at the very beginning of the revert? That might work, but there would be a lot of code using a read_deleted\u003d\u0027yes\u0027 context which otherwise wouldn\u0027t expect to be doing anything with deleted records, so that could get interesting, like weird lazy-load type failures, but that\u0027s less of a concern with your change here:\n\nhttps://review.openstack.org/#/c/575190/\n\nThere are also DB APIs which hard-code the read_deleted value, but those would be bug fixes. Plus if the context itself is just globally targeted to read_deleted\u003dyes maybe it would be OK, but again, it\u0027s just a lot of code that wouldn\u0027t expect that and we could see some strange side effects.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":219,"context_line":"* Update the ``Migration.status`` to ``reverted`` (normally ``revert_resize``"},{"line_number":220,"context_line":"  on the destination compute would do this)."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":"* Destroy the instance and its related records from the target cell database."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Limitations"},{"line_number":225,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_32391041","line":222,"in_reply_to":"3f79a3b5_c6568bd1","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":224,"context_line":"Limitations"},{"line_number":225,"context_line":"-----------"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"* Cells v1 will not be supported."},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"* nova-network will not be supported; this mostly pertains to the nova-network"},{"line_number":230,"context_line":"  specific cell DB tables like ``fixed_ips`` and ``security_groups``."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_48de043e","line":227,"updated":"2018-12-03 20:41:28.000000000","message":"Um, duh :)","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":224,"context_line":"Limitations"},{"line_number":225,"context_line":"-----------"},{"line_number":226,"context_line":""},{"line_number":227,"context_line":"* Cells v1 will not be supported."},{"line_number":228,"context_line":""},{"line_number":229,"context_line":"* nova-network will not be supported; this mostly pertains to the nova-network"},{"line_number":230,"context_line":"  specific cell DB tables like ``fixed_ips`` and ``security_groups``."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_f8d56044","line":227,"in_reply_to":"3f79a3b5_48de043e","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"108cea53445b454939cab95958426243cfe777fa","unresolved":false,"context_lines":[{"line_number":244,"context_line":"  REST API response could timeout. Until the `2.34 microversion`_, the live"},{"line_number":245,"context_line":"  migrate API had the same problem. As a future enhancement, the resize"},{"line_number":246,"context_line":"  and cold migrate API actions could similarly be changed to use an RPC cast"},{"line_number":247,"context_line":"  in a new microversion."},{"line_number":248,"context_line":""},{"line_number":249,"context_line":"* Shelve operations on the compute do not support rescheduling like server"},{"line_number":250,"context_line":"  create and traditional resize where if something like a resource claim on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_c8b3f40b","line":247,"updated":"2018-12-03 20:41:28.000000000","message":"Do we need to make them \"long call\" type so that we don\u0027t have RPC timeouts either?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":244,"context_line":"  REST API response could timeout. Until the `2.34 microversion`_, the live"},{"line_number":245,"context_line":"  migrate API had the same problem. As a future enhancement, the resize"},{"line_number":246,"context_line":"  and cold migrate API actions could similarly be changed to use an RPC cast"},{"line_number":247,"context_line":"  in a new microversion."},{"line_number":248,"context_line":""},{"line_number":249,"context_line":"* Shelve operations on the compute do not support rescheduling like server"},{"line_number":250,"context_line":"  create and traditional resize where if something like a resource claim on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_e0e10b99","line":247,"in_reply_to":"3f79a3b5_51ed4c21","updated":"2018-12-14 16:44:37.000000000","message":"Default where? I don\u0027t think there\u0027s anything set in stone about that in our http plumbing, and I surely expect it\u0027s easy and reasonably common to need to up that.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"932c28bae508e35a76f6515c1d7dbe3d326beaf8","unresolved":false,"context_lines":[{"line_number":244,"context_line":"  REST API response could timeout. Until the `2.34 microversion`_, the live"},{"line_number":245,"context_line":"  migrate API had the same problem. As a future enhancement, the resize"},{"line_number":246,"context_line":"  and cold migrate API actions could similarly be changed to use an RPC cast"},{"line_number":247,"context_line":"  in a new microversion."},{"line_number":248,"context_line":""},{"line_number":249,"context_line":"* Shelve operations on the compute do not support rescheduling like server"},{"line_number":250,"context_line":"  create and traditional resize where if something like a resource claim on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d1f39ce4","line":247,"in_reply_to":"3f79a3b5_aea24197","updated":"2018-12-14 22:14:43.000000000","message":"Sorry, this was stuck in my buffer from earlier in the week and I didn\u0027t realize it when I committed changes this morning.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0b0eb0584917d39fef2d63eca0e99789101324e7","unresolved":false,"context_lines":[{"line_number":244,"context_line":"  REST API response could timeout. Until the `2.34 microversion`_, the live"},{"line_number":245,"context_line":"  migrate API had the same problem. As a future enhancement, the resize"},{"line_number":246,"context_line":"  and cold migrate API actions could similarly be changed to use an RPC cast"},{"line_number":247,"context_line":"  in a new microversion."},{"line_number":248,"context_line":""},{"line_number":249,"context_line":"* Shelve operations on the compute do not support rescheduling like server"},{"line_number":250,"context_line":"  create and traditional resize where if something like a resource claim on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_51ed4c21","line":247,"in_reply_to":"3f79a3b5_c8b3f40b","updated":"2018-12-03 22:17:31.000000000","message":"I think the default HTTP response timeout is 60 seconds isn\u0027t it? If so, that matches our default rpc_response_timeout so I\u0027m not sure how much it would matter.\n\nIf we move the policy check to the API then we could make an educated decision on whether or not to do an RPC cast or a long call...","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":244,"context_line":"  REST API response could timeout. Until the `2.34 microversion`_, the live"},{"line_number":245,"context_line":"  migrate API had the same problem. As a future enhancement, the resize"},{"line_number":246,"context_line":"  and cold migrate API actions could similarly be changed to use an RPC cast"},{"line_number":247,"context_line":"  in a new microversion."},{"line_number":248,"context_line":""},{"line_number":249,"context_line":"* Shelve operations on the compute do not support rescheduling like server"},{"line_number":250,"context_line":"  create and traditional resize where if something like a resource claim on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_d8d3c437","line":247,"in_reply_to":"3f79a3b5_d1f39ce4","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":244,"context_line":"  REST API response could timeout. Until the `2.34 microversion`_, the live"},{"line_number":245,"context_line":"  migrate API had the same problem. As a future enhancement, the resize"},{"line_number":246,"context_line":"  and cold migrate API actions could similarly be changed to use an RPC cast"},{"line_number":247,"context_line":"  in a new microversion."},{"line_number":248,"context_line":""},{"line_number":249,"context_line":"* Shelve operations on the compute do not support rescheduling like server"},{"line_number":250,"context_line":"  create and traditional resize where if something like a resource claim on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_aea24197","line":247,"in_reply_to":"3f79a3b5_e0e10b99","updated":"2018-12-14 21:51:02.000000000","message":"As we\u0027ve discussed elsewhere this week (cinder gate bugs with timeouts), I was thinking of KSA session timeouts but apparently those are set to 600 seconds by default, so yeah that\u0027s not a problem. As noted, we could also do the policy check in the API and based on that determine if we should do an RPC cast to conductor or use the long_rpc_timeout. It seems weird that API calls conductor during resize anyway so I tend to think we should just change that to a cast if we\u0027re going to fiddle the cross-cell resize flow (granted, depending on the host we get back from the scheduler, we might not do a cross-cell resize).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":264,"context_line":"are several pending open implementation questions which will likely just be"},{"line_number":265,"context_line":"sorted out during code review. At a high level, those are:"},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"1. Is a ``MigrationContext`` needed for tracking resources during the resize?"},{"line_number":268,"context_line":"   Currently, unshelve does a ``ResourceTracker.instance_claim`` which does"},{"line_number":269,"context_line":"   (a) not consider the new flavor when resizing and (b) does not consider"},{"line_number":270,"context_line":"   a migration - or populate the ``instance.migration_context`` field."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_3ca50e03","line":267,"updated":"2018-12-14 16:44:37.000000000","message":"Personally I was hoping we would get to the place of always having a context when we\u0027re moving something. It\u0027s just so much easier to see \"is this thing moving, or was it moving\" if you have that context. Looking up migrations that may not be complete for the instance is not a good way. So, it may not be required for what you\u0027re doing here, but I\u0027d sure rather have it for consistency. Also, since we\u0027re trying to behave like cold migration, it would seem most consistent to also have it for this operation as well. Just MHO.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":264,"context_line":"are several pending open implementation questions which will likely just be"},{"line_number":265,"context_line":"sorted out during code review. At a high level, those are:"},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"1. Is a ``MigrationContext`` needed for tracking resources during the resize?"},{"line_number":268,"context_line":"   Currently, unshelve does a ``ResourceTracker.instance_claim`` which does"},{"line_number":269,"context_line":"   (a) not consider the new flavor when resizing and (b) does not consider"},{"line_number":270,"context_line":"   a migration - or populate the ``instance.migration_context`` field."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_bc0ea5d6","line":267,"in_reply_to":"3f79a3b5_2ea87172","updated":"2018-12-20 00:10:11.000000000","message":"+1 on the consistency reason. In the earlier replies, I was thinking about your comment, \"passing a Migration object is more explicit\" which, I could see. But if we did that, I\u0027d want us to (eventually) change the other moves to become consistent with it so we do a similar thing for all moves.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":264,"context_line":"are several pending open implementation questions which will likely just be"},{"line_number":265,"context_line":"sorted out during code review. At a high level, those are:"},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"1. Is a ``MigrationContext`` needed for tracking resources during the resize?"},{"line_number":268,"context_line":"   Currently, unshelve does a ``ResourceTracker.instance_claim`` which does"},{"line_number":269,"context_line":"   (a) not consider the new flavor when resizing and (b) does not consider"},{"line_number":270,"context_line":"   a migration - or populate the ``instance.migration_context`` field."}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2ea87172","line":267,"in_reply_to":"3f79a3b5_3ca50e03","updated":"2018-12-14 21:51:02.000000000","message":"I\u0027ve noted a few times in replies above (which you prompted my thinking on this) where I think we could use a migration context to stash things during the flow, like if we\u0027re doing a confirm/revert, storing the original image_ref, I\u0027ve thought about using it to store port/volume attachment IDs from the validation step, etc, so I think I\u0027ll probably end up using it for those reasons and the consistency reason.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":264,"context_line":"are several pending open implementation questions which will likely just be"},{"line_number":265,"context_line":"sorted out during code review. At a high level, those are:"},{"line_number":266,"context_line":""},{"line_number":267,"context_line":"1. Is a ``MigrationContext`` needed for tracking resources during the resize?"},{"line_number":268,"context_line":"   Currently, unshelve does a ``ResourceTracker.instance_claim`` which does"},{"line_number":269,"context_line":"   (a) not consider the new flavor when resizing and (b) does not consider"},{"line_number":270,"context_line":"   a migration - or populate the ``instance.migration_context`` field."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_527854f7","line":267,"in_reply_to":"3f79a3b5_bc0ea5d6","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":271,"context_line":"   A ``MigrationContext`` is mainly used for two things:"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"   a) Routing neutron network-related events, like ``network-vif-plugged``, to"},{"line_number":274,"context_line":"      the source and target host while the instance is moving."},{"line_number":275,"context_line":"   b) Tracking resource claims for NUMA and PCI devices."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"   As such, we could use a ``ResourceTracker.move_claim`` during unshelve in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_1c3cd2bb","line":274,"updated":"2018-12-14 16:44:37.000000000","message":"Presumably since you\u0027re doing a full shelve and then unshelve, it\u0027s fine to just switch the destination at some point and not need the parallel delivery.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":271,"context_line":"   A ``MigrationContext`` is mainly used for two things:"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"   a) Routing neutron network-related events, like ``network-vif-plugged``, to"},{"line_number":274,"context_line":"      the source and target host while the instance is moving."},{"line_number":275,"context_line":"   b) Tracking resource claims for NUMA and PCI devices."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"   As such, we could use a ``ResourceTracker.move_claim`` during unshelve in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_eec11933","line":274,"in_reply_to":"3f79a3b5_1c3cd2bb","updated":"2018-12-14 21:51:02.000000000","message":"Yeah for now I don\u0027t need the migration_context for this if I change the instance mapping to point at the target cell before doing the unshelve, since unshelve is what triggers the event and by the time that happens, the target has set instance.host to point at the target host.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":271,"context_line":"   A ``MigrationContext`` is mainly used for two things:"},{"line_number":272,"context_line":""},{"line_number":273,"context_line":"   a) Routing neutron network-related events, like ``network-vif-plugged``, to"},{"line_number":274,"context_line":"      the source and target host while the instance is moving."},{"line_number":275,"context_line":"   b) Tracking resource claims for NUMA and PCI devices."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"   As such, we could use a ``ResourceTracker.move_claim`` during unshelve in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_727d58e6","line":274,"in_reply_to":"3f79a3b5_eec11933","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":305,"context_line":"   And if so, would this require a microversion change for the new behavior"},{"line_number":306,"context_line":"   even though it is an admin-only API (cold migrate, not resize) by default?"},{"line_number":307,"context_line":"   For the purposes of this spec, I have opted to leave that for a future"},{"line_number":308,"context_line":"   enhancement."},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"3. Rather than polling, would it be better to use an RPC call with a long"},{"line_number":311,"context_line":"   timeout during the conductor orchestration of the resize? One issue with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_1cb1322d","line":308,"updated":"2018-12-14 16:44:37.000000000","message":"I would think that targeting a host in another cell would be an important use case. Maybe not for v1, but eventually. If we don\u0027t do it in v1, how does the behavior fit? The users can\u0027t know if a host is in another cell (which is good and means we don\u0027t have to have a cells-specific reason for why something isn\u0027t allowed), but presumably if the host is in the hypervisor list, they expect to be able to move it. We could re-use the \"there\u0027s no space there\" failure, but that is likely to confuse people who can assert that there is.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":305,"context_line":"   And if so, would this require a microversion change for the new behavior"},{"line_number":306,"context_line":"   even though it is an admin-only API (cold migrate, not resize) by default?"},{"line_number":307,"context_line":"   For the purposes of this spec, I have opted to leave that for a future"},{"line_number":308,"context_line":"   enhancement."},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"3. Rather than polling, would it be better to use an RPC call with a long"},{"line_number":311,"context_line":"   timeout during the conductor orchestration of the resize? One issue with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_3df045db","line":308,"in_reply_to":"3f79a3b5_0fc43a0b","updated":"2018-12-20 10:12:55.000000000","message":"Yeah, this will be useful","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":305,"context_line":"   And if so, would this require a microversion change for the new behavior"},{"line_number":306,"context_line":"   even though it is an admin-only API (cold migrate, not resize) by default?"},{"line_number":307,"context_line":"   For the purposes of this spec, I have opted to leave that for a future"},{"line_number":308,"context_line":"   enhancement."},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"3. Rather than polling, would it be better to use an RPC call with a long"},{"line_number":311,"context_line":"   timeout during the conductor orchestration of the resize? One issue with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_6efc2974","line":308,"in_reply_to":"3f79a3b5_1cb1322d","updated":"2018-12-14 21:51:02.000000000","message":"I wrote this before you got me thinking about moving the policy check to the API, so I think if we move the policy check to the API (I think we should for the RPC call issue), then we could just build that into this check as well, i.e. was a target host specified and does the user pass the policy check for cross-cell resize? If so, check if the host is in any cell, otherwise if they fail the policy check then just do what we do today (restrict to the same cell the instance is in).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":305,"context_line":"   And if so, would this require a microversion change for the new behavior"},{"line_number":306,"context_line":"   even though it is an admin-only API (cold migrate, not resize) by default?"},{"line_number":307,"context_line":"   For the purposes of this spec, I have opted to leave that for a future"},{"line_number":308,"context_line":"   enhancement."},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"3. Rather than polling, would it be better to use an RPC call with a long"},{"line_number":311,"context_line":"   timeout during the conductor orchestration of the resize? One issue with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_18f13cce","line":308,"in_reply_to":"3f79a3b5_3df045db","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":305,"context_line":"   And if so, would this require a microversion change for the new behavior"},{"line_number":306,"context_line":"   even though it is an admin-only API (cold migrate, not resize) by default?"},{"line_number":307,"context_line":"   For the purposes of this spec, I have opted to leave that for a future"},{"line_number":308,"context_line":"   enhancement."},{"line_number":309,"context_line":""},{"line_number":310,"context_line":"3. Rather than polling, would it be better to use an RPC call with a long"},{"line_number":311,"context_line":"   timeout during the conductor orchestration of the resize? One issue with"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_0fc43a0b","line":308,"in_reply_to":"3f79a3b5_6efc2974","updated":"2018-12-20 00:10:11.000000000","message":"Agreed, it feels like cold migrate with a target host should fit into cross-cell cold migrate. Ideally, we would be transparent about cells here, but also understood it might not be possible to do all the things in v1.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":313,"context_line":"   of the status of the operation. Also, it could consume an RPC connection"},{"line_number":314,"context_line":"   from the pool for a long amount of time (while creating a snapshot), which"},{"line_number":315,"context_line":"   may force operators to increase the ``rpc_conn_pool_size`` configuration"},{"line_number":316,"context_line":"   value."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"4. When reverting a resize, should we even attempt to use the original source"},{"line_number":319,"context_line":"   host or just ask the scheduler for a fresh host in the source cell? Thanks"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_bcc91e87","line":316,"updated":"2018-12-14 16:44:37.000000000","message":"I guess it depends on how often you poll. If you\u0027re going to poll at half the timeout value or so, then the heartbeats will be smaller. The code will be cleaner if you don\u0027t poll, and/or you can still poll even if you get timeouts if you want to handle rabbit failures (although I think that\u0027s probably not worth the trouble).\n\nI\u0027m not sure this really affects the number of connections that are made to rabbit, although maybe it does and I just don\u0027t know. Wouldn\u0027t the polling be done from conductor and thus go direct to that cell database anyway?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":313,"context_line":"   of the status of the operation. Also, it could consume an RPC connection"},{"line_number":314,"context_line":"   from the pool for a long amount of time (while creating a snapshot), which"},{"line_number":315,"context_line":"   may force operators to increase the ``rpc_conn_pool_size`` configuration"},{"line_number":316,"context_line":"   value."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"4. When reverting a resize, should we even attempt to use the original source"},{"line_number":319,"context_line":"   host or just ask the scheduler for a fresh host in the source cell? Thanks"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_eff77e5a","line":316,"in_reply_to":"3f79a3b5_0e301552","updated":"2018-12-20 00:10:11.000000000","message":"Not sure about this one, also don\u0027t feel I really know which way is better. I\u0027d prefer the long_rpc_timeout for its simplicity and expand to polling if it\u0027s found to be needed, but no strong opinion either way.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":313,"context_line":"   of the status of the operation. Also, it could consume an RPC connection"},{"line_number":314,"context_line":"   from the pool for a long amount of time (while creating a snapshot), which"},{"line_number":315,"context_line":"   may force operators to increase the ``rpc_conn_pool_size`` configuration"},{"line_number":316,"context_line":"   value."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"4. When reverting a resize, should we even attempt to use the original source"},{"line_number":319,"context_line":"   host or just ask the scheduler for a fresh host in the source cell? Thanks"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_0e301552","line":316,"in_reply_to":"3f79a3b5_bcc91e87","updated":"2018-12-14 21:51:02.000000000","message":"Yes the polling happens in (super)conductor:\n\nhttps://review.openstack.org/#/c/603930/18/nova/conductor/tasks/cross_cell_migrate.py@167\n\nI have added dedicated config options for the polling:\n\nhttps://review.openstack.org/#/c/603930/18/nova/conf/conductor.py\n\nThe poll interval defaults to 60sec to match rpc_response_timeout default and the overall time is 1800sec to match the long_rpc_timeout default.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":313,"context_line":"   of the status of the operation. Also, it could consume an RPC connection"},{"line_number":314,"context_line":"   from the pool for a long amount of time (while creating a snapshot), which"},{"line_number":315,"context_line":"   may force operators to increase the ``rpc_conn_pool_size`` configuration"},{"line_number":316,"context_line":"   value."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"4. When reverting a resize, should we even attempt to use the original source"},{"line_number":319,"context_line":"   host or just ask the scheduler for a fresh host in the source cell? Thanks"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_f0818747","line":316,"in_reply_to":"3f79a3b5_eff77e5a","updated":"2018-12-20 20:39:00.000000000","message":"RPC call with a long timeout is easier, I just don\u0027t know if it holds a connection in use from the pool (I would assume it does since it\u0027s a synchronous call). However, if we change the design (as discussed above) to not use shelve/unshelve, then conductor could create the snapshot and if that times out, it\u0027s not really a big deal because we haven\u0027t done any kind of guest transfer or data migration to the new cell.\n\nI think I mostly went with the polling design first because I was thinking about conductor as an external orchestrator, i.e. if I were doing this using only REST API or something, I\u0027d have to be polling the server for state changes before I can take my next step.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":313,"context_line":"   of the status of the operation. Also, it could consume an RPC connection"},{"line_number":314,"context_line":"   from the pool for a long amount of time (while creating a snapshot), which"},{"line_number":315,"context_line":"   may force operators to increase the ``rpc_conn_pool_size`` configuration"},{"line_number":316,"context_line":"   value."},{"line_number":317,"context_line":""},{"line_number":318,"context_line":"4. When reverting a resize, should we even attempt to use the original source"},{"line_number":319,"context_line":"   host or just ask the scheduler for a fresh host in the source cell? Thanks"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_18ca9c6c","line":316,"in_reply_to":"3f79a3b5_f0818747","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":324,"context_line":"   for whatever reason, we should attempt to find another host in the source"},{"line_number":325,"context_line":"   cell rather than fail the revert. And if we are going to attempt to find"},{"line_number":326,"context_line":"   an alternative host in the source cell anyway, should we just do that from"},{"line_number":327,"context_line":"   the beginning of the revert operation?"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5cc1ea4f","line":327,"updated":"2018-12-14 16:44:37.000000000","message":"It seems the most equal to regular migrate/resize if you do keep the same host. If you don\u0027t, you could get a different guest topology, newer (or older) cpu, etc, which I think is contrary to the current expectation fo what revert-resize means. Not sure that\u0027s a huge deal, and maybe it\u0027s not worth the trouble. However, if you can avoid offloading and keep the same host, then you avoid the glance traffic as I mentioned above.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":324,"context_line":"   for whatever reason, we should attempt to find another host in the source"},{"line_number":325,"context_line":"   cell rather than fail the revert. And if we are going to attempt to find"},{"line_number":326,"context_line":"   an alternative host in the source cell anyway, should we just do that from"},{"line_number":327,"context_line":"   the beginning of the revert operation?"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_1282ccc9","line":327,"in_reply_to":"3f79a3b5_106be386","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":324,"context_line":"   for whatever reason, we should attempt to find another host in the source"},{"line_number":325,"context_line":"   cell rather than fail the revert. And if we are going to attempt to find"},{"line_number":326,"context_line":"   an alternative host in the source cell anyway, should we just do that from"},{"line_number":327,"context_line":"   the beginning of the revert operation?"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_4f5a325d","line":327,"in_reply_to":"3f79a3b5_2e52b16b","updated":"2018-12-20 00:10:11.000000000","message":"I\u0027d think to keep the same host here. Revert resize has meant \"undo the resize and put it back the way it was\" and showing up on a completely different host might be quite the surprise.\n\nIf I\u0027m reading the code correctly, it looks like for regular migrate, if there\u0027s no longer space on the source host for the instance during revert, the instance will go into ERROR state and the revert will fail. Should we not be consistent with the behavior for cross-cell migrate?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":324,"context_line":"   for whatever reason, we should attempt to find another host in the source"},{"line_number":325,"context_line":"   cell rather than fail the revert. And if we are going to attempt to find"},{"line_number":326,"context_line":"   an alternative host in the source cell anyway, should we just do that from"},{"line_number":327,"context_line":"   the beginning of the revert operation?"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_fdbc0dd7","line":327,"in_reply_to":"3f79a3b5_4f5a325d","updated":"2018-12-20 10:12:55.000000000","message":"prefer the original host is a good idea. But should we limit the alternatives to only the source cell? I mean, as a user I may care about revert to the original flavor, I may not care about which cell it is in, so maybe we should consider all posibile hosts as alternatives?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":324,"context_line":"   for whatever reason, we should attempt to find another host in the source"},{"line_number":325,"context_line":"   cell rather than fail the revert. And if we are going to attempt to find"},{"line_number":326,"context_line":"   an alternative host in the source cell anyway, should we just do that from"},{"line_number":327,"context_line":"   the beginning of the revert operation?"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2e52b16b","line":327,"in_reply_to":"3f79a3b5_5cc1ea4f","updated":"2018-12-14 21:51:02.000000000","message":"What I\u0027ve got written today is we use the requested_destination field on the request spec to try and get the source host first, and failing that (if we lost some resource claim race or something) then we ask for any in the source cell that fits the original request (original image/flavor). But my problem is I need to drop the allocations held against the source host by the migration record before hitting the scheduler, which means we could theoretically lose that race. That\u0027s the convo above on L196.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":324,"context_line":"   for whatever reason, we should attempt to find another host in the source"},{"line_number":325,"context_line":"   cell rather than fail the revert. And if we are going to attempt to find"},{"line_number":326,"context_line":"   an alternative host in the source cell anyway, should we just do that from"},{"line_number":327,"context_line":"   the beginning of the revert operation?"},{"line_number":328,"context_line":""},{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_106be386","line":327,"in_reply_to":"3f79a3b5_fdbc0dd7","updated":"2018-12-20 20:39:00.000000000","message":"Same reply as on L193 - trying to revert a cross-cell resize by going wherever fits could work but seems much riskier when we know the source host worked for that guest, and for that matter, the source cell itself worked for storage and network connections, which are things the scheduler doesn\u0027t necessarily know about (unless the server is confined to host aggregates or something).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"},{"line_number":331,"context_line":"   will we require that all alternates are in the same cell? That seems rather"},{"line_number":332,"context_line":"   limiting but might be a decent initial compromise."},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"6. Should we disallow attaching/detaching volumes from a resized server during"},{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_bc97de4c","line":332,"updated":"2018-12-14 16:44:37.000000000","message":"I would say pick hosts in one cell, just like we do for build. Your weigher could also weigh hosts higher in cells with more available hosts or something.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"},{"line_number":331,"context_line":"   will we require that all alternates are in the same cell? That seems rather"},{"line_number":332,"context_line":"   limiting but might be a decent initial compromise."},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"6. Should we disallow attaching/detaching volumes from a resized server during"},{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_3287d0da","line":332,"in_reply_to":"3f79a3b5_4f11d25e","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"},{"line_number":331,"context_line":"   will we require that all alternates are in the same cell? That seems rather"},{"line_number":332,"context_line":"   limiting but might be a decent initial compromise."},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"6. Should we disallow attaching/detaching volumes from a resized server during"},{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_4f11d25e","line":332,"in_reply_to":"3f79a3b5_ae45619e","updated":"2018-12-20 00:10:11.000000000","message":"+1 be consistent with build","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":329,"context_line":"5. How will \"reschedules\" work between selected target hosts? What if those"},{"line_number":330,"context_line":"   hosts are all in different cells? Or once we pick a \"primary\" selected host"},{"line_number":331,"context_line":"   will we require that all alternates are in the same cell? That seems rather"},{"line_number":332,"context_line":"   limiting but might be a decent initial compromise."},{"line_number":333,"context_line":""},{"line_number":334,"context_line":"6. Should we disallow attaching/detaching volumes from a resized server during"},{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_ae45619e","line":332,"in_reply_to":"3f79a3b5_bc97de4c","updated":"2018-12-14 21:51:02.000000000","message":"Maybe the scheduler code would already handle this for me once the primary selected target is chosen:\n\nhttps://github.com/openstack/nova/blob/bb446c66ec1b9858e343bbfcddb6e3bdc916b431/nova/scheduler/filter_scheduler.py#L409\n\nI guess it does, I forgot about that.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"},{"line_number":336,"context_line":"   to mirror the changes from the target cell database back into the source"},{"line_number":337,"context_line":"   cell database. Regardless of cross-cell resize, that might be a bad idea"},{"line_number":338,"context_line":"   for `detaching the root volume`_ while resized anyway."},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_1c9e1252","line":338,"updated":"2018-12-14 16:44:37.000000000","message":"So, I would tend to say \"why the eff do we allow that anyway?\" However, there are some providers where you can\u0027t attach a volume to certain size flavors, or to instances in certain (potentially old) DCs. So, if you think about it from the user\u0027s perspective, they might be doing a resize to a new or larger flavor in order to get volume support at all (or a specific volume type). So they do the resize, attach a volume to check performance, and then may decide to revert.\n\nI do think it seems weird to care about bringing that volume back to the reverted instance, and is probably an outstanding issue if that volume can\u0027t be attached to the source host. I wonder if just not doing that (bringing attached volumes back to the source with the revert) would be rage-inducing or go unnoticed.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"3b1121ecf34c53e976b989d313f443de341d1613","unresolved":false,"context_lines":[{"line_number":334,"context_line":"6. Should we disallow attaching/detaching volumes from a resized server during"},{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"},{"line_number":336,"context_line":"   to mirror the changes from the target cell database back into the source"},{"line_number":337,"context_line":"   cell database. Regardless of cross-cell resize, that might be a bad idea"},{"line_number":338,"context_line":"   for `detaching the root volume`_ while resized anyway."},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_fd6acd4e","line":338,"range":{"start_line":337,"start_character":51,"end_line":338,"end_character":57},"updated":"2018-12-20 10:12:55.000000000","message":"Yeah, I don\u0027t like that too. For this open discussion, how do we know it is a cross-cell resized instance? by checking migration.coress_cell_move?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"},{"line_number":336,"context_line":"   to mirror the changes from the target cell database back into the source"},{"line_number":337,"context_line":"   cell database. Regardless of cross-cell resize, that might be a bad idea"},{"line_number":338,"context_line":"   for `detaching the root volume`_ while resized anyway."},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2e95d1e2","line":338,"in_reply_to":"3f79a3b5_1c9e1252","updated":"2018-12-14 21:51:02.000000000","message":"Since I wrote this I added the code to the conductor cross-cell resize task to mirror a volume attached to the server while resized in the other cell remains attached to the server upon revert back to the source cell so I\u0027ve already got this covered:\n\nhttps://review.openstack.org/#/c/603930/18/nova/conductor/tasks/cross_cell_migrate.py@638\n\nBut I need to add functional test wrinkles for that.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"},{"line_number":336,"context_line":"   to mirror the changes from the target cell database back into the source"},{"line_number":337,"context_line":"   cell database. Regardless of cross-cell resize, that might be a bad idea"},{"line_number":338,"context_line":"   for `detaching the root volume`_ while resized anyway."},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d237c5db","line":338,"in_reply_to":"3f79a3b5_2e95d1e2","updated":"2018-12-20 00:10:11.000000000","message":"I did not actually know we allowed this for regular migrate -- I thought it would have been kicked out by some invalid state checks in the compute/api layer.\n\nBut Dan\u0027s user example makes sense. I feel like if you\u0027ve detached/attached volumes while in VERIFY_RESIZE, we shouldn\u0027t try to change anything or make it reflect the state before the user detached/attached. I think one could argue that would be weird and unexpected to say, detach a newer volume the user attached and attach back an older one. But again, I can\u0027t say I know what users would want in this case.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":334,"context_line":"6. Should we disallow attaching/detaching volumes from a resized server during"},{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"},{"line_number":336,"context_line":"   to mirror the changes from the target cell database back into the source"},{"line_number":337,"context_line":"   cell database. Regardless of cross-cell resize, that might be a bad idea"},{"line_number":338,"context_line":"   for `detaching the root volume`_ while resized anyway."},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_f2686822","line":338,"range":{"start_line":337,"start_character":51,"end_line":338,"end_character":57},"in_reply_to":"3f79a3b5_30161ff5","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"6e7f6e2c85d7861222ea6f094fe82d6757290818","unresolved":false,"context_lines":[{"line_number":334,"context_line":"6. Should we disallow attaching/detaching volumes from a resized server during"},{"line_number":335,"context_line":"   a cross-cell resize? It makes the revert flow more complicated when we have"},{"line_number":336,"context_line":"   to mirror the changes from the target cell database back into the source"},{"line_number":337,"context_line":"   cell database. Regardless of cross-cell resize, that might be a bad idea"},{"line_number":338,"context_line":"   for `detaching the root volume`_ while resized anyway."},{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_30161ff5","line":338,"range":{"start_line":337,"start_character":51,"end_line":338,"end_character":57},"in_reply_to":"3f79a3b5_fd6acd4e","updated":"2018-12-20 20:39:00.000000000","message":"\u003e Yeah, I don\u0027t like that too. For this open discussion, how do we\n \u003e know it is a cross-cell resized instance? by checking\n \u003e migration.coress_cell_move?\n\nYes.\n\nI\u0027ve also updated my functional test to attach a volume while resized into the other cell and assert that it remains attached during confirm/revert, so that\u0027s already working.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"},{"line_number":342,"context_line":"   anything goes wrong?"},{"line_number":343,"context_line":""},{"line_number":344,"context_line":".. _2.56 microversion: https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id51"},{"line_number":345,"context_line":".. _target host exists: https://github.com/openstack/nova/blob/c295e395d/nova/compute/api.py#L3570"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_bcfcbe74","line":342,"updated":"2018-12-14 16:44:37.000000000","message":"*shrug*. I could see both as beneficial depending on what you value (speed or safety).","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"},{"line_number":342,"context_line":"   anything goes wrong?"},{"line_number":343,"context_line":""},{"line_number":344,"context_line":".. _2.56 microversion: https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id51"},{"line_number":345,"context_line":".. _target host exists: https://github.com/openstack/nova/blob/c295e395d/nova/compute/api.py#L3570"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_92755cfd","line":342,"in_reply_to":"3f79a3b5_aea1e13d","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":339,"context_line":""},{"line_number":340,"context_line":"7. During revert, should we wait to shelve offload the instance from the target"},{"line_number":341,"context_line":"   cell until we have successfully unshelved in the source cell in case"},{"line_number":342,"context_line":"   anything goes wrong?"},{"line_number":343,"context_line":""},{"line_number":344,"context_line":".. _2.56 microversion: https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id51"},{"line_number":345,"context_line":".. _target host exists: https://github.com/openstack/nova/blob/c295e395d/nova/compute/api.py#L3570"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_aea1e13d","line":342,"in_reply_to":"3f79a3b5_bcfcbe74","updated":"2018-12-14 21:51:02.000000000","message":"For cross-cell resize I value safety over speed. And I\u0027m reminded again that I wrote this *before* we talked about how we don\u0027t want to unshelve on revert from the snapshot in the target (because the image might be too big for the old flavor). So given that, on revert, shelve offload from target is really just about cleaning up the target hypervisor and detaching volumes/ports, there is no snapshot performed. Given that, the answer to this question might be \"yes? try to unshelve back to source first before cleaning up the target\".","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":351,"context_line":""},{"line_number":352,"context_line":"Users (or cloud operators) could force existing servers to be snapshot,"},{"line_number":353,"context_line":"destroyed and then re-created from snapshot with a new flavor in a new cell."},{"line_number":354,"context_line":"This could be highly disruptive to those workloads especially if specific"},{"line_number":355,"context_line":"volumes and ports are attached. In addition, it would require all"},{"line_number":356,"context_line":"multi-cell deployments to orchestrate their own cross-cell migration tooling."},{"line_number":357,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_5ceb2aa5","line":354,"range":{"start_line":354,"start_character":0,"end_line":354,"end_character":50},"updated":"2018-12-14 16:44:37.000000000","message":"Not sure it\u0027s really more disruptive than what you\u0027re doing here, but it is more work :)","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":351,"context_line":""},{"line_number":352,"context_line":"Users (or cloud operators) could force existing servers to be snapshot,"},{"line_number":353,"context_line":"destroyed and then re-created from snapshot with a new flavor in a new cell."},{"line_number":354,"context_line":"This could be highly disruptive to those workloads especially if specific"},{"line_number":355,"context_line":"volumes and ports are attached. In addition, it would require all"},{"line_number":356,"context_line":"multi-cell deployments to orchestrate their own cross-cell migration tooling."},{"line_number":357,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_d26025d4","line":354,"range":{"start_line":354,"start_character":0,"end_line":354,"end_character":50},"in_reply_to":"3f79a3b5_2e63911a","updated":"2018-12-20 00:10:11.000000000","message":"Yeah... I can\u0027t call what\u0027s going on here non-disruptive or less disruptive. :)","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":351,"context_line":""},{"line_number":352,"context_line":"Users (or cloud operators) could force existing servers to be snapshot,"},{"line_number":353,"context_line":"destroyed and then re-created from snapshot with a new flavor in a new cell."},{"line_number":354,"context_line":"This could be highly disruptive to those workloads especially if specific"},{"line_number":355,"context_line":"volumes and ports are attached. In addition, it would require all"},{"line_number":356,"context_line":"multi-cell deployments to orchestrate their own cross-cell migration tooling."},{"line_number":357,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2e63911a","line":354,"range":{"start_line":354,"start_character":0,"end_line":354,"end_character":50},"in_reply_to":"3f79a3b5_5ceb2aa5","updated":"2018-12-14 21:51:02.000000000","message":"Heh, that\u0027s fair yeah. I will remove that part whenever I rev this. Nova natively dealing with the orchestration is the primary motivator behind all this.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":351,"context_line":""},{"line_number":352,"context_line":"Users (or cloud operators) could force existing servers to be snapshot,"},{"line_number":353,"context_line":"destroyed and then re-created from snapshot with a new flavor in a new cell."},{"line_number":354,"context_line":"This could be highly disruptive to those workloads especially if specific"},{"line_number":355,"context_line":"volumes and ports are attached. In addition, it would require all"},{"line_number":356,"context_line":"multi-cell deployments to orchestrate their own cross-cell migration tooling."},{"line_number":357,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_b272e010","line":354,"range":{"start_line":354,"start_character":0,"end_line":354,"end_character":50},"in_reply_to":"3f79a3b5_d26025d4","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":390,"context_line":"obviously the flow of notifications during a resize will be different for"},{"line_number":391,"context_line":"a cross-cell resize (as will the related instance action events) since they"},{"line_number":392,"context_line":"will include notifications about shelve/unshelve. As long as consumers of"},{"line_number":393,"context_line":"resize notifications are clear about the start/end states, they should be OK."},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"If desired, new versioned notifications could be added to denote a cross-cell"},{"line_number":396,"context_line":"resize is being performed, either as part of this blueprint or as a future"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_9c078270","line":393,"updated":"2018-12-14 16:44:37.000000000","message":"One thing that may really confuse things looking at notifications is that notifications for a given instance uuid will go \"created\", \"migrating\", and then just disappear from the current notifications queue, while on another rabbit an instance will go straight to \"migrated\", \"running\" or something, right? I mean, assuming they\u0027re not all sending notifications to a single rabbit.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"3838efbe47d64cd4660e1a1d6d6bed66e7f8db35","unresolved":false,"context_lines":[{"line_number":390,"context_line":"obviously the flow of notifications during a resize will be different for"},{"line_number":391,"context_line":"a cross-cell resize (as will the related instance action events) since they"},{"line_number":392,"context_line":"will include notifications about shelve/unshelve. As long as consumers of"},{"line_number":393,"context_line":"resize notifications are clear about the start/end states, they should be OK."},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"If desired, new versioned notifications could be added to denote a cross-cell"},{"line_number":396,"context_line":"resize is being performed, either as part of this blueprint or as a future"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ffd0ebdf_125bac87","line":393,"in_reply_to":"1f769fc5_8741710e","updated":"2019-01-03 01:24:35.000000000","message":"Done","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5a0cf3e568685a75308cdc67fe8c789cb48f6f8e","unresolved":false,"context_lines":[{"line_number":390,"context_line":"obviously the flow of notifications during a resize will be different for"},{"line_number":391,"context_line":"a cross-cell resize (as will the related instance action events) since they"},{"line_number":392,"context_line":"will include notifications about shelve/unshelve. As long as consumers of"},{"line_number":393,"context_line":"resize notifications are clear about the start/end states, they should be OK."},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"If desired, new versioned notifications could be added to denote a cross-cell"},{"line_number":396,"context_line":"resize is being performed, either as part of this blueprint or as a future"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f769fc5_8741710e","line":393,"in_reply_to":"3f79a3b5_2e3cf1e8","updated":"2019-01-02 17:32:09.000000000","message":"\u003e  Although didn\u0027t we say\n \u003e notifications in multi-cell should go to a single MQ?\n \u003e \n \u003e https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#notifications\n\nI think that says operators may or likely want unified notifications, and I\u0027m sure they do in most cases. However, for a large cloud that\u0027s likely not reasonable, and certainly the edgy people looking for fault domains aren\u0027t going to do that. Perhaps we just document that the full lifecycle may not look like you expect if you have cross-cell migrations enabled. But, we probably need a new notification (or field of the existing migrated one) that makes sure to say something like \"okay this instance is ... potentially no longer going to notify on this bus\".","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"a56d3d8cb50cf983be7a1fcc58a472762af2fb58","unresolved":false,"context_lines":[{"line_number":390,"context_line":"obviously the flow of notifications during a resize will be different for"},{"line_number":391,"context_line":"a cross-cell resize (as will the related instance action events) since they"},{"line_number":392,"context_line":"will include notifications about shelve/unshelve. As long as consumers of"},{"line_number":393,"context_line":"resize notifications are clear about the start/end states, they should be OK."},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"If desired, new versioned notifications could be added to denote a cross-cell"},{"line_number":396,"context_line":"resize is being performed, either as part of this blueprint or as a future"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_1298ddc7","line":393,"in_reply_to":"3f79a3b5_2e3cf1e8","updated":"2018-12-20 00:10:11.000000000","message":"Hm, I had thought notifications go on a single MQ across all cells but I can\u0027t say I know what deployers are doing on that.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":390,"context_line":"obviously the flow of notifications during a resize will be different for"},{"line_number":391,"context_line":"a cross-cell resize (as will the related instance action events) since they"},{"line_number":392,"context_line":"will include notifications about shelve/unshelve. As long as consumers of"},{"line_number":393,"context_line":"resize notifications are clear about the start/end states, they should be OK."},{"line_number":394,"context_line":""},{"line_number":395,"context_line":"If desired, new versioned notifications could be added to denote a cross-cell"},{"line_number":396,"context_line":"resize is being performed, either as part of this blueprint or as a future"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_2e3cf1e8","line":393,"in_reply_to":"3f79a3b5_9c078270","updated":"2018-12-14 21:51:02.000000000","message":"Hmm, yeah maybe, honestly I\u0027m not really sure how people deal with notifications. I think most just have notifications dealt with on the same MQ as everything else even if that makes their MQ melt, so I would think people would split those out to balance that load, and if you\u0027re doing multi-cell anyway for MQ load balancing (among other reasons like hardware separation, DB load balancing) then you might be sophisticated enough to have those going to different MQs (or at least just the cell MQ). Although didn\u0027t we say notifications in multi-cell should go to a single MQ?\n\nhttps://docs.openstack.org/nova/latest/user/cellsv2-layout.html#notifications","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dd9724709809e80ee29b13c2704a72504c6191c","unresolved":false,"context_lines":[{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Also, deployments which enable this feature may need to scale out their"},{"line_number":417,"context_line":"conductor workers which will be doing a lot of the orchestration work"},{"line_number":418,"context_line":"rather than inter-compute coordination like a normal resize."},{"line_number":419,"context_line":""},{"line_number":420,"context_line":"Other deployer impact"},{"line_number":421,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_fc6c7635","line":418,"updated":"2018-12-14 16:44:37.000000000","message":"Maybe. It depends on how many cross-cell resizes start happening, but I wouldn\u0027t expect the occasional cross-cell resize to suddenly cause a huge spike in the number of conductor workers needed. This is just one additional long-running conductor greenthread per cross-cell resize that lives for the duration. There\u0027s not a whole lot of additional db proxy traffic happening or anything, right?","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"ac38e8a468455115914d310d198f7aa3d71bcdc5","unresolved":false,"context_lines":[{"line_number":415,"context_line":""},{"line_number":416,"context_line":"Also, deployments which enable this feature may need to scale out their"},{"line_number":417,"context_line":"conductor workers which will be doing a lot of the orchestration work"},{"line_number":418,"context_line":"rather than inter-compute coordination like a normal resize."},{"line_number":419,"context_line":""},{"line_number":420,"context_line":"Other deployer impact"},{"line_number":421,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f79a3b5_ee559921","line":418,"in_reply_to":"3f79a3b5_fc6c7635","updated":"2018-12-14 21:51:02.000000000","message":"Shouldn\u0027t be; as you said the polling happens directly in conductor so it\u0027s direct-to-database for those queries.","commit_id":"8e92f0156e94e81dfac6fd03341f925e4f65fb95"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"6d807203f3f15255cbd2d258d3523687c1e82f6f","unresolved":false,"context_lines":[{"line_number":76,"context_line":"* Resized instance: an instance with status ``VERIFY_RESIZE``."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* Super conductor: in a `split-MQ`_ deployment, the super conductor is running"},{"line_number":79,"context_line":"  a the \"top\" and has access to the API database and thus can communicate with"},{"line_number":80,"context_line":"  the cells over RPC and directly to the cell databases."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. _split-MQ: https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#multiple-cells"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_18dc2d45","line":79,"range":{"start_line":79,"start_character":2,"end_line":79,"end_character":3},"updated":"2019-01-03 07:01:05.000000000","message":"at","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":76,"context_line":"* Resized instance: an instance with status ``VERIFY_RESIZE``."},{"line_number":77,"context_line":""},{"line_number":78,"context_line":"* Super conductor: in a `split-MQ`_ deployment, the super conductor is running"},{"line_number":79,"context_line":"  a the \"top\" and has access to the API database and thus can communicate with"},{"line_number":80,"context_line":"  the cells over RPC and directly to the cell databases."},{"line_number":81,"context_line":""},{"line_number":82,"context_line":".. _split-MQ: https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#multiple-cells"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_6fd55bb9","line":79,"range":{"start_line":79,"start_character":2,"end_line":79,"end_character":3},"in_reply_to":"ffd0ebdf_18dc2d45","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":196,"context_line":"**Prep Resize at Dest**"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":199,"context_line":"new method ``prep_cross_cell_resize_at_dest`` on the dest compute service"},{"line_number":200,"context_line":"which will:"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"* Call ``ResourceTracker.resize_claim()`` on the potential dest host in the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_c6bc74bd","line":199,"range":{"start_line":199,"start_character":13,"end_line":199,"end_character":43},"updated":"2019-01-03 20:03:59.000000000","message":"prep_snapshot_based_resize_at_dest","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":196,"context_line":"**Prep Resize at Dest**"},{"line_number":197,"context_line":""},{"line_number":198,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":199,"context_line":"new method ``prep_cross_cell_resize_at_dest`` on the dest compute service"},{"line_number":200,"context_line":"which will:"},{"line_number":201,"context_line":""},{"line_number":202,"context_line":"* Call ``ResourceTracker.resize_claim()`` on the potential dest host in the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_efe06b99","line":199,"range":{"start_line":199,"start_character":13,"end_line":199,"end_character":43},"in_reply_to":"ffd0ebdf_c6bc74bd","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5f36492194033f34f33814d5f9951ebd96e54fa","unresolved":false,"context_lines":[{"line_number":223,"context_line":"**Prep Resize at Source**"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":226,"context_line":"new method ``prep_cross_cell_resize_at_source`` on the source compute service"},{"line_number":227,"context_line":"which will behave very similar to how shelve works, but also coincides with"},{"line_number":228,"context_line":"how the ``resize_instance`` method works during a traditional resize:"},{"line_number":229,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_de2a028f","line":226,"range":{"start_line":226,"start_character":13,"end_line":226,"end_character":45},"updated":"2019-01-03 17:55:32.000000000","message":"I think you should consider calling this something more generic so it\u0027s not confusing if we want to be able to use it for generic resizes where the computes can\u0027t talk to each other. Not a huge deal here, but when you\u0027re writing the code...","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ace0bb994a9ce123fc57027b2604f66a4b1e31c6","unresolved":false,"context_lines":[{"line_number":223,"context_line":"**Prep Resize at Source**"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":226,"context_line":"new method ``prep_cross_cell_resize_at_source`` on the source compute service"},{"line_number":227,"context_line":"which will behave very similar to how shelve works, but also coincides with"},{"line_number":228,"context_line":"how the ``resize_instance`` method works during a traditional resize:"},{"line_number":229,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_a3b7e2d8","line":226,"range":{"start_line":226,"start_character":13,"end_line":226,"end_character":45},"in_reply_to":"ffd0ebdf_60f25009","updated":"2019-01-03 19:11:45.000000000","message":"Anything. Even just \"prep_snapshot_based_resize\" would be fine.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":223,"context_line":"**Prep Resize at Source**"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":226,"context_line":"new method ``prep_cross_cell_resize_at_source`` on the source compute service"},{"line_number":227,"context_line":"which will behave very similar to how shelve works, but also coincides with"},{"line_number":228,"context_line":"how the ``resize_instance`` method works during a traditional resize:"},{"line_number":229,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_e6c89875","line":226,"range":{"start_line":226,"start_character":13,"end_line":226,"end_character":45},"in_reply_to":"ffd0ebdf_a3b7e2d8","updated":"2019-01-03 20:03:59.000000000","message":"OK I\u0027ll go with prep_snapshot_based_resize_at_x since I find the at_source/at_dest useful for keeping these straight - it\u0027s useful for the live migration methods, and always a source of confusion for the cold migrate resize methods where one can never remember where each method is run.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"36ace178d7d4d735c13862ca6f35dadec536eab0","unresolved":false,"context_lines":[{"line_number":223,"context_line":"**Prep Resize at Source**"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":226,"context_line":"new method ``prep_cross_cell_resize_at_source`` on the source compute service"},{"line_number":227,"context_line":"which will behave very similar to how shelve works, but also coincides with"},{"line_number":228,"context_line":"how the ``resize_instance`` method works during a traditional resize:"},{"line_number":229,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_60f25009","line":226,"range":{"start_line":226,"start_character":13,"end_line":226,"end_character":45},"in_reply_to":"ffd0ebdf_de2a028f","updated":"2019-01-03 19:03:27.000000000","message":"So just prep_resize_at_source? I think that would likely be confused with the existing prep_resize (which is at dest) and resize_instance (which is at source). IOW, I don\u0027t know how to make this sufficiently generic without causing confusion with the existing resize flow, especially when the new stuff is going to be special purpose for the cross-cell case.\n\nMaybe you\u0027re thinking something like, \"prep_isolated_disk_resize_at_source\" or \"prep_no_ssh_resize_at_source\" or \"prep_snapshot_resize_at_source\"?","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":223,"context_line":"**Prep Resize at Source**"},{"line_number":224,"context_line":""},{"line_number":225,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":226,"context_line":"new method ``prep_cross_cell_resize_at_source`` on the source compute service"},{"line_number":227,"context_line":"which will behave very similar to how shelve works, but also coincides with"},{"line_number":228,"context_line":"how the ``resize_instance`` method works during a traditional resize:"},{"line_number":229,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_2f00b334","line":226,"range":{"start_line":226,"start_character":13,"end_line":226,"end_character":45},"in_reply_to":"ffd0ebdf_e6c89875","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"* Destroy the guest on the hypervisor. This is necessary to disconnect volumes"},{"line_number":238,"context_line":"  and unplug VIFs from the source host. Note that we do not free up tracked"},{"line_number":239,"context_line":"  resources on the source host at this point nor change the instance host/node"},{"line_number":240,"context_line":"  values in the database in case we revert or need to recover from a failed"},{"line_number":241,"context_line":"  migration."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"* Delete old volume attachments and update the BlockDeviceMapping records"},{"line_number":244,"context_line":"  with new placeholder volume attachments which will be used on the dest host."}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_8688ac1f","line":241,"range":{"start_line":237,"start_character":0,"end_line":241,"end_character":12},"updated":"2019-01-03 20:03:59.000000000","message":"Per the discussion below, this changes to destroy with destroy_disks\u003dFalse which will unplug VIFs, disconnect volumes and undefine the domain (like power off). Then on confirm we do a hard destroy of the guest (including disks) and on revert we power_on the guest which will connect volumes, plug vifs and spawn the guest (actually that\u0027s what finish_revert_migration does so we might just be able to re-use that on the source host during revert like normal).","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""},{"line_number":237,"context_line":"* Destroy the guest on the hypervisor. This is necessary to disconnect volumes"},{"line_number":238,"context_line":"  and unplug VIFs from the source host. Note that we do not free up tracked"},{"line_number":239,"context_line":"  resources on the source host at this point nor change the instance host/node"},{"line_number":240,"context_line":"  values in the database in case we revert or need to recover from a failed"},{"line_number":241,"context_line":"  migration."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"* Delete old volume attachments and update the BlockDeviceMapping records"},{"line_number":244,"context_line":"  with new placeholder volume attachments which will be used on the dest host."}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_8f943fea","line":241,"range":{"start_line":237,"start_character":0,"end_line":241,"end_character":12},"in_reply_to":"ffd0ebdf_8688ac1f","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":254,"context_line":".. _bug 1659062: https://bugs.launchpad.net/nova/+bug/1659062"},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"If the migration fails at this point, any snapshot image created should be"},{"line_number":257,"context_line":"deleted. Recovery of the instance depends on what state it is in. If it is"},{"line_number":258,"context_line":"only stopped, the user should be able to start it or reboot it. If the guest"},{"line_number":259,"context_line":"was destroyed, then the user will need to rebuild it on the source host."},{"line_number":260,"context_line":""},{"line_number":261,"context_line":"**Finish Resize at Dest**"},{"line_number":262,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_26cb0054","line":259,"range":{"start_line":257,"start_character":9,"end_line":259,"end_character":72},"updated":"2019-01-03 20:03:59.000000000","message":"I think this just changes to (start [or reboot] the server).","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":254,"context_line":".. _bug 1659062: https://bugs.launchpad.net/nova/+bug/1659062"},{"line_number":255,"context_line":""},{"line_number":256,"context_line":"If the migration fails at this point, any snapshot image created should be"},{"line_number":257,"context_line":"deleted. Recovery of the instance depends on what state it is in. If it is"},{"line_number":258,"context_line":"only stopped, the user should be able to start it or reboot it. If the guest"},{"line_number":259,"context_line":"was destroyed, then the user will need to rebuild it on the source host."},{"line_number":260,"context_line":""},{"line_number":261,"context_line":"**Finish Resize at Dest**"},{"line_number":262,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_8f30bf09","line":259,"range":{"start_line":257,"start_character":9,"end_line":259,"end_character":72},"in_reply_to":"ffd0ebdf_26cb0054","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5f36492194033f34f33814d5f9951ebd96e54fa","unresolved":false,"context_lines":[{"line_number":266,"context_line":"values, instance action events, etc"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":269,"context_line":"new method ``finish_cross_cell_resize_at_dest`` on the dest compute service"},{"line_number":270,"context_line":"which will behave very similar to how unshelve works, but also coincides with"},{"line_number":271,"context_line":"how the ``finish_resize`` method works during a traditional resize:"},{"line_number":272,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_1e0aca25","line":269,"range":{"start_line":269,"start_character":13,"end_line":269,"end_character":45},"updated":"2019-01-03 17:55:32.000000000","message":"Same.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":266,"context_line":"values, instance action events, etc"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":269,"context_line":"new method ``finish_cross_cell_resize_at_dest`` on the dest compute service"},{"line_number":270,"context_line":"which will behave very similar to how unshelve works, but also coincides with"},{"line_number":271,"context_line":"how the ``finish_resize`` method works during a traditional resize:"},{"line_number":272,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_469f2450","line":269,"range":{"start_line":269,"start_character":13,"end_line":269,"end_character":45},"in_reply_to":"ffd0ebdf_1e0aca25","updated":"2019-01-03 20:03:59.000000000","message":"Will change to finish_snapshot_based_resize_at_dest.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":266,"context_line":"values, instance action events, etc"},{"line_number":267,"context_line":""},{"line_number":268,"context_line":"Conductor will make a synchronous RPC call (using ``long_rpc_timeout``) to a"},{"line_number":269,"context_line":"new method ``finish_cross_cell_resize_at_dest`` on the dest compute service"},{"line_number":270,"context_line":"which will behave very similar to how unshelve works, but also coincides with"},{"line_number":271,"context_line":"how the ``finish_resize`` method works during a traditional resize:"},{"line_number":272,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_cf2d67a9","line":269,"range":{"start_line":269,"start_character":13,"end_line":269,"end_character":45},"in_reply_to":"ffd0ebdf_469f2450","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5f36492194033f34f33814d5f9951ebd96e54fa","unresolved":false,"context_lines":[{"line_number":284,"context_line":"  event to be routed from the API before continuing."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Delete the temporary snapshot image (if one was created). This is similar to"},{"line_number":287,"context_line":"  how unshelve works where the shelved snapshot image is deleted."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* Mark the instance as resized."},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_6056d009","line":287,"updated":"2019-01-03 17:55:32.000000000","message":"Don\u0027t we need to avoid deleting the image until it\u0027s confirmed? That would be in line with how resize works, where changes on the dest aren\u0027t sync\u0027d back to the source as they may have been related to the dest host, configuration, etc.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"36ace178d7d4d735c13862ca6f35dadec536eab0","unresolved":false,"context_lines":[{"line_number":284,"context_line":"  event to be routed from the API before continuing."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Delete the temporary snapshot image (if one was created). This is similar to"},{"line_number":287,"context_line":"  how unshelve works where the shelved snapshot image is deleted."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* Mark the instance as resized."},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_a0d1185a","line":287,"in_reply_to":"ffd0ebdf_6056d009","updated":"2019-01-03 19:03:27.000000000","message":"This is just talking about the snapshot image in glance, like a shelved snapshot image. This wouldn\u0027t exist for volume-backed servers, and I was trying to align this with how unshelve works, which is once you\u0027ve spawned the guest at the new place, you don\u0027t need that snapshot image anymore so we delete it from glance. If you\u0027re talking about the root disk image on the source host, that\u0027s a different thing.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":284,"context_line":"  event to be routed from the API before continuing."},{"line_number":285,"context_line":""},{"line_number":286,"context_line":"* Delete the temporary snapshot image (if one was created). This is similar to"},{"line_number":287,"context_line":"  how unshelve works where the shelved snapshot image is deleted."},{"line_number":288,"context_line":""},{"line_number":289,"context_line":"* Mark the instance as resized."},{"line_number":290,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_6f18fb80","line":287,"in_reply_to":"ffd0ebdf_a0d1185a","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"6d807203f3f15255cbd2d258d3523687c1e82f6f","unresolved":false,"context_lines":[{"line_number":291,"context_line":"Back in conductor, we need to:"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"* Mark the target cell instance record as ``hidden\u003dFalse`` so it will show"},{"line_number":294,"context_line":"  up when listing servers. Note that because of how the `API filters`_"},{"line_number":295,"context_line":"  duplicate instance records, even if the user is listing servers at this exact"},{"line_number":296,"context_line":"  moment only one copy of the instance will be returned."},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"* Update the instance mapping to point at the target cell. This is so that"},{"line_number":299,"context_line":"  the confirm/revert actions will be performed on the resized instance in the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_862f5af5","line":296,"range":{"start_line":294,"start_character":26,"end_line":296,"end_character":56},"updated":"2019-01-03 07:01:05.000000000","message":"Hmm, doesn\u0027t seem right, the filter you mentioned here only matches instance uuid, so we might end up with the record that has host\u003dold_host, and we should return host\u003dnew_host now.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"5f71f8b7f283f4822ecce31ab95a0d468df18616","unresolved":false,"context_lines":[{"line_number":291,"context_line":"Back in conductor, we need to:"},{"line_number":292,"context_line":""},{"line_number":293,"context_line":"* Mark the target cell instance record as ``hidden\u003dFalse`` so it will show"},{"line_number":294,"context_line":"  up when listing servers. Note that because of how the `API filters`_"},{"line_number":295,"context_line":"  duplicate instance records, even if the user is listing servers at this exact"},{"line_number":296,"context_line":"  moment only one copy of the instance will be returned."},{"line_number":297,"context_line":""},{"line_number":298,"context_line":"* Update the instance mapping to point at the target cell. This is so that"},{"line_number":299,"context_line":"  the confirm/revert actions will be performed on the resized instance in the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_d2d679f2","line":296,"range":{"start_line":294,"start_character":26,"end_line":296,"end_character":56},"in_reply_to":"ffd0ebdf_862f5af5","updated":"2019-01-03 14:18:23.000000000","message":"Since the instances are in separate databases, I have no way of atomically updating both records at the same time to swap the hidden values so they are mutually exclusive. So yes for a tiny window you could get the instance from the source cell if you\u0027re listing instances, but I don\u0027t think that really matters since you\u0027re getting that instance up until the point we switch over anyway. Even in a normal resize if you\u0027re polling the instance you can\u0027t determine when the host value is going to change, which is why it\u0027s more important to care about terminal states (VERIFY_RESIZE) if you\u0027re polling for the completion of the operation.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":314,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":315,"context_line":"is True, the API will:"},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"* RPC call to the source compute to drop the move claim (free up tracked"},{"line_number":318,"context_line":"  resource usage for the source node)."},{"line_number":319,"context_line":"  Note that we could potentially omit this step since the next run of the"},{"line_number":320,"context_line":"  ``update_available_resource`` periodic task should not find the deleted"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_86ebccae","line":317,"updated":"2019-01-03 20:03:59.000000000","message":"and destroy the guest (similar to the driver.confirm_migration method).","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":314,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":315,"context_line":"is True, the API will:"},{"line_number":316,"context_line":""},{"line_number":317,"context_line":"* RPC call to the source compute to drop the move claim (free up tracked"},{"line_number":318,"context_line":"  resource usage for the source node)."},{"line_number":319,"context_line":"  Note that we could potentially omit this step since the next run of the"},{"line_number":320,"context_line":"  ``update_available_resource`` periodic task should not find the deleted"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_ef038b0e","line":317,"in_reply_to":"ffd0ebdf_86ebccae","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5f36492194033f34f33814d5f9951ebd96e54fa","unresolved":false,"context_lines":[{"line_number":372,"context_line":"  flavor and original image, attach volumes and update port bindings, spawn"},{"line_number":373,"context_line":"  the guest and swap source node allocations held by the migration record in"},{"line_number":374,"context_line":"  placement to the instance record. This is sort of like a hybrid of unshelve,"},{"line_number":375,"context_line":"  finish_revert_resize and rebuild."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Limitations"},{"line_number":378,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_606fb0c5","line":375,"updated":"2019-01-03 17:55:32.000000000","message":"Where do we get the root disk here? Is it still available because we never deleted it (despite destroy()in the instance)? If not, we need to redeploy from the snapshot you deleted above right?","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":372,"context_line":"  flavor and original image, attach volumes and update port bindings, spawn"},{"line_number":373,"context_line":"  the guest and swap source node allocations held by the migration record in"},{"line_number":374,"context_line":"  placement to the instance record. This is sort of like a hybrid of unshelve,"},{"line_number":375,"context_line":"  finish_revert_resize and rebuild."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Limitations"},{"line_number":378,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_ba9f03b3","line":375,"in_reply_to":"ffd0ebdf_4652c469","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"36ace178d7d4d735c13862ca6f35dadec536eab0","unresolved":false,"context_lines":[{"line_number":372,"context_line":"  flavor and original image, attach volumes and update port bindings, spawn"},{"line_number":373,"context_line":"  the guest and swap source node allocations held by the migration record in"},{"line_number":374,"context_line":"  placement to the instance record. This is sort of like a hybrid of unshelve,"},{"line_number":375,"context_line":"  finish_revert_resize and rebuild."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Limitations"},{"line_number":378,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_a0bb58e3","line":375,"in_reply_to":"ffd0ebdf_606fb0c5","updated":"2019-01-03 19:03:27.000000000","message":"This is a fresh spawn so the root disk is recreated, again, like unshelve. But good point in that we\u0027d need to either (1) not destroy the root disk on the source host or (2) spawn from the snapshot image and only delete the snapshot image when we confirm/revert/delete the instance.\n\nThe driver.destroy method does have a destroy_disks boolean which defaults to True. I was using destroy because I need to power off the guest and disconnect volumes, which is what migrate_disk_and_power_off does in resize_instance (normal flow, on the source host, which doesn\u0027t unplug vifs for some reason, but that\u0027s probably why driver.finish_migration doesn\u0027t wait for vif plugging events on the dest...).\n\nSo if I don\u0027t destroy the disks on the source, that gets me what I need I guess - we\u0027d still unplug vifs, undefine the domain (like stop), and disconnect volumes. Then on revert we\u0027d start the guest (which for the libvirt driver is a hard reboot which will connect volumes and plug vifs - but not wait for the vif-plugged event).","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ace0bb994a9ce123fc57027b2604f66a4b1e31c6","unresolved":false,"context_lines":[{"line_number":372,"context_line":"  flavor and original image, attach volumes and update port bindings, spawn"},{"line_number":373,"context_line":"  the guest and swap source node allocations held by the migration record in"},{"line_number":374,"context_line":"  placement to the instance record. This is sort of like a hybrid of unshelve,"},{"line_number":375,"context_line":"  finish_revert_resize and rebuild."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Limitations"},{"line_number":378,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_a32a82e4","line":375,"in_reply_to":"ffd0ebdf_a0bb58e3","updated":"2019-01-03 19:11:45.000000000","message":"Right, that was my comment above. AFAICT, the only place you persist the state of the image in case of rollback is in the snapshot which you said you deleted at the end of the initial resize.\n\nNot deleting the disks is more efficient, but I think we\u0027ve had plenty of problems with leaking those in the past (and maybe reaping them in the image cache periodic?). So, tbh, just re-spawning from the image in the first pass seems cleaner to me. That way you can delete everything completely from the source assuming you\u0027re going to confirm it. But, whatever you think as long as you\u0027ve got it somewhere :)","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":372,"context_line":"  flavor and original image, attach volumes and update port bindings, spawn"},{"line_number":373,"context_line":"  the guest and swap source node allocations held by the migration record in"},{"line_number":374,"context_line":"  placement to the instance record. This is sort of like a hybrid of unshelve,"},{"line_number":375,"context_line":"  finish_revert_resize and rebuild."},{"line_number":376,"context_line":""},{"line_number":377,"context_line":"Limitations"},{"line_number":378,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_4652c469","line":375,"in_reply_to":"ffd0ebdf_a32a82e4","updated":"2019-01-03 20:03:59.000000000","message":"I\u0027ll update the spec to not delete the disks on the source host so on revert (or recovery in case the migration failed or timed out), the user just needs to reboot the server to fix it. I\u0027ll make a note that we could completely destroy and re-spawn from the snapshot as an alternative on revert, but then we have to make sure to cleanup the snapshot image in multiple places (confirm/revert flows) rather than just once the instance is resized at the dest host.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":386,"context_line":""},{"line_number":387,"context_line":".. _\\_poll_unconfirmed_resizes: https://github.com/openstack/nova/blob/c295e395d/nova/compute/manager.py#L7082"},{"line_number":388,"context_line":""},{"line_number":389,"context_line":"Open questions"},{"line_number":390,"context_line":"--------------"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"1. Rather than conductor making synchronous RPC calls during the resize with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_c6f4745e","line":389,"updated":"2019-01-03 20:03:59.000000000","message":"Based on feedback of the two questions in here, I\u0027ll just change this to \u0027Known issues\u0027 and assert what we\u0027re going to do (use long_rpc_timeout until we need something more granular and not worry about new action event names).","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":386,"context_line":""},{"line_number":387,"context_line":".. _\\_poll_unconfirmed_resizes: https://github.com/openstack/nova/blob/c295e395d/nova/compute/manager.py#L7082"},{"line_number":388,"context_line":""},{"line_number":389,"context_line":"Open questions"},{"line_number":390,"context_line":"--------------"},{"line_number":391,"context_line":""},{"line_number":392,"context_line":"1. Rather than conductor making synchronous RPC calls during the resize with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_9ad1df5a","line":389,"in_reply_to":"ffd0ebdf_c6f4745e","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f78d2a4fc39a14d345dc21562a83b7c38ec68087","unresolved":false,"context_lines":[{"line_number":395,"context_line":"   disk could take a long time to upload (or download) it might be better to"},{"line_number":396,"context_line":"   add new options for controlling those timeouts. Alternatively, should"},{"line_number":397,"context_line":"   conductor do an RPC cast to compute and then poll the database for when an"},{"line_number":398,"context_line":"   operation in the compute is complete (with a configurable timeout)?"},{"line_number":399,"context_line":""},{"line_number":400,"context_line":"2. One semantic difference in the API will be different events under the"},{"line_number":401,"context_line":"   instance actions records during a resize, since the events are created via"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_008ee477","line":398,"updated":"2019-01-03 18:03:42.000000000","message":"As I said before, I think this is what long_rpc_timeout is for, it does the polling for us, and we\u0027ll notice success or failure a lot quicker if we use it instead of polling the db.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"36ace178d7d4d735c13862ca6f35dadec536eab0","unresolved":false,"context_lines":[{"line_number":395,"context_line":"   disk could take a long time to upload (or download) it might be better to"},{"line_number":396,"context_line":"   add new options for controlling those timeouts. Alternatively, should"},{"line_number":397,"context_line":"   conductor do an RPC cast to compute and then poll the database for when an"},{"line_number":398,"context_line":"   operation in the compute is complete (with a configurable timeout)?"},{"line_number":399,"context_line":""},{"line_number":400,"context_line":"2. One semantic difference in the API will be different events under the"},{"line_number":401,"context_line":"   instance actions records during a resize, since the events are created via"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_832c1e48","line":398,"in_reply_to":"ffd0ebdf_008ee477","updated":"2019-01-03 19:03:27.000000000","message":"Sure I\u0027m OK with the RPC call but do we want to re-use long_rpc_timeout for that or add a new option? Right now long_rpc_timeout is just used for things like live migration methods and select_destinations to the scheduler, none of which should take as long as a snapshot might take. So I wasn\u0027t sure if we should add new config options for the RPC calls during a cross-cell resize, or even something less generic but tied to snapshot, long_rpc_snapshot_timeout? I might be over thinking it though and it could be something that could be tweaked later on if people need the granularity, or if we wanted to apply a multiplier to long_rpc_timeout if it\u0027s an instance that is going to require a snapshot.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":395,"context_line":"   disk could take a long time to upload (or download) it might be better to"},{"line_number":396,"context_line":"   add new options for controlling those timeouts. Alternatively, should"},{"line_number":397,"context_line":"   conductor do an RPC cast to compute and then poll the database for when an"},{"line_number":398,"context_line":"   operation in the compute is complete (with a configurable timeout)?"},{"line_number":399,"context_line":""},{"line_number":400,"context_line":"2. One semantic difference in the API will be different events under the"},{"line_number":401,"context_line":"   instance actions records during a resize, since the events are created via"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_da53e7e1","line":398,"in_reply_to":"ffd0ebdf_26da20e9","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ace0bb994a9ce123fc57027b2604f66a4b1e31c6","unresolved":false,"context_lines":[{"line_number":395,"context_line":"   disk could take a long time to upload (or download) it might be better to"},{"line_number":396,"context_line":"   add new options for controlling those timeouts. Alternatively, should"},{"line_number":397,"context_line":"   conductor do an RPC cast to compute and then poll the database for when an"},{"line_number":398,"context_line":"   operation in the compute is complete (with a configurable timeout)?"},{"line_number":399,"context_line":""},{"line_number":400,"context_line":"2. One semantic difference in the API will be different events under the"},{"line_number":401,"context_line":"   instance actions records during a resize, since the events are created via"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_a31362b8","line":398,"in_reply_to":"ffd0ebdf_832c1e48","updated":"2019-01-03 19:11:45.000000000","message":"Ah, but it\u0027s an hour by default or something right? I guess I\u0027d add an option when someone says we need one and not just obligatorially, but whatever.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":395,"context_line":"   disk could take a long time to upload (or download) it might be better to"},{"line_number":396,"context_line":"   add new options for controlling those timeouts. Alternatively, should"},{"line_number":397,"context_line":"   conductor do an RPC cast to compute and then poll the database for when an"},{"line_number":398,"context_line":"   operation in the compute is complete (with a configurable timeout)?"},{"line_number":399,"context_line":""},{"line_number":400,"context_line":"2. One semantic difference in the API will be different events under the"},{"line_number":401,"context_line":"   instance actions records during a resize, since the events are created via"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_26da20e9","line":398,"in_reply_to":"ffd0ebdf_a31362b8","updated":"2019-01-03 20:03:59.000000000","message":"30 minutes by default, but yeah I\u0027ll just use what we have and we can add a new option later if needed.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f78d2a4fc39a14d345dc21562a83b7c38ec68087","unresolved":false,"context_lines":[{"line_number":407,"context_line":"   action record, it is hard to know how much this matters. It may matter,"},{"line_number":408,"context_line":"   however, for deployments that want to hide as much as possible the fact that"},{"line_number":409,"context_line":"   servers are resized across cells which could otherwise be deduced from the"},{"line_number":410,"context_line":"   event names."},{"line_number":411,"context_line":""},{"line_number":412,"context_line":"Edge cases"},{"line_number":413,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_80f734f6","line":410,"updated":"2019-01-03 18:03:42.000000000","message":"It\u0027s internals leaking out of the api, which people already can\u0027t really depend on (or shouldn\u0027t be). So I\u0027m fairly meh on worrying about this.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":407,"context_line":"   action record, it is hard to know how much this matters. It may matter,"},{"line_number":408,"context_line":"   however, for deployments that want to hide as much as possible the fact that"},{"line_number":409,"context_line":"   servers are resized across cells which could otherwise be deduced from the"},{"line_number":410,"context_line":"   event names."},{"line_number":411,"context_line":""},{"line_number":412,"context_line":"Edge cases"},{"line_number":413,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_fa502bd7","line":410,"in_reply_to":"ffd0ebdf_23e69218","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"36ace178d7d4d735c13862ca6f35dadec536eab0","unresolved":false,"context_lines":[{"line_number":407,"context_line":"   action record, it is hard to know how much this matters. It may matter,"},{"line_number":408,"context_line":"   however, for deployments that want to hide as much as possible the fact that"},{"line_number":409,"context_line":"   servers are resized across cells which could otherwise be deduced from the"},{"line_number":410,"context_line":"   event names."},{"line_number":411,"context_line":""},{"line_number":412,"context_line":"Edge cases"},{"line_number":413,"context_line":"----------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_23e69218","line":410,"in_reply_to":"ffd0ebdf_80f734f6","updated":"2019-01-03 19:03:27.000000000","message":"Yeah I\u0027m not very worried about it either. As noted we could override the function name to masquerade as the traditional resize methods, but it becomes a game of diminishing returns.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f78d2a4fc39a14d345dc21562a83b7c38ec68087","unresolved":false,"context_lines":[{"line_number":419,"context_line":"   the source cell)."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"2. When `routing network events`_ in the API, if the instance has a migration"},{"line_number":422,"context_line":"   context it will lookup the migration record based in id rather than uuid"},{"line_number":423,"context_line":"   which may be wrong if the migration context was created in a different cell"},{"line_number":424,"context_line":"   database where the id primary key on the migration record is different."},{"line_number":425,"context_line":"   It is not clear if this will be a problem but that code might need to change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_20dc4873","line":422,"range":{"start_line":422,"start_character":56,"end_line":422,"end_character":58},"updated":"2019-01-03 18:03:42.000000000","message":"on","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":419,"context_line":"   the source cell)."},{"line_number":420,"context_line":""},{"line_number":421,"context_line":"2. When `routing network events`_ in the API, if the instance has a migration"},{"line_number":422,"context_line":"   context it will lookup the migration record based in id rather than uuid"},{"line_number":423,"context_line":"   which may be wrong if the migration context was created in a different cell"},{"line_number":424,"context_line":"   database where the id primary key on the migration record is different."},{"line_number":425,"context_line":"   It is not clear if this will be a problem but that code might need to change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_ba8e232c","line":422,"range":{"start_line":422,"start_character":56,"end_line":422,"end_character":58},"in_reply_to":"ffd0ebdf_20dc4873","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f78d2a4fc39a14d345dc21562a83b7c38ec68087","unresolved":false,"context_lines":[{"line_number":423,"context_line":"   which may be wrong if the migration context was created in a different cell"},{"line_number":424,"context_line":"   database where the id primary key on the migration record is different."},{"line_number":425,"context_line":"   It is not clear if this will be a problem but that code might need to change"},{"line_number":426,"context_line":"   to use migration uuid rather than id."},{"line_number":427,"context_line":""},{"line_number":428,"context_line":"3. It is possible to attach/detach volumes to/from a resized server. Because of"},{"line_number":429,"context_line":"   this, mirroring those block device mapping changes from the target cell DB"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_00bca403","line":426,"updated":"2019-01-03 18:03:42.000000000","message":"It does this based on the migration context. So, when you\u0027re coping that (and the migration record) over, you could just fix it then and there and nothing else has to worry about it being wrong. In fact, I think this is the only legit solution, else you\u0027ve got an id pointing at what is likely someone else\u0027s migration, which\u0027d be bad\u0027n\u0027stuff.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"36ace178d7d4d735c13862ca6f35dadec536eab0","unresolved":false,"context_lines":[{"line_number":423,"context_line":"   which may be wrong if the migration context was created in a different cell"},{"line_number":424,"context_line":"   database where the id primary key on the migration record is different."},{"line_number":425,"context_line":"   It is not clear if this will be a problem but that code might need to change"},{"line_number":426,"context_line":"   to use migration uuid rather than id."},{"line_number":427,"context_line":""},{"line_number":428,"context_line":"3. It is possible to attach/detach volumes to/from a resized server. Because of"},{"line_number":429,"context_line":"   this, mirroring those block device mapping changes from the target cell DB"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_03c6ee68","line":426,"in_reply_to":"ffd0ebdf_00bca403","updated":"2019-01-03 19:03:27.000000000","message":"The migration context gets created during prep_cross_cell_resize_at_dest, which is in the target cell db. If it\u0027s the first migration record in that target cell the instance.migration_context.migration_id would be 1, but the migration record in the source cell would be 1065. If we attempt to lookup the migration_id\u003d1 in the source cell that\u0027s going to be the wrong one, as you noted (it might not even exist if it was deleted/purged).\n\nAre you saying when copying the migration_context from the target db to the source cell db that I just update the migratoin_id field to point at the source migration.id? Yeah that\u0027s probably fine - I was thinking I couldn\u0027t update ids, but that\u0027s only for the primary key on an object, not the reference in this case.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ace0bb994a9ce123fc57027b2604f66a4b1e31c6","unresolved":false,"context_lines":[{"line_number":423,"context_line":"   which may be wrong if the migration context was created in a different cell"},{"line_number":424,"context_line":"   database where the id primary key on the migration record is different."},{"line_number":425,"context_line":"   It is not clear if this will be a problem but that code might need to change"},{"line_number":426,"context_line":"   to use migration uuid rather than id."},{"line_number":427,"context_line":""},{"line_number":428,"context_line":"3. It is possible to attach/detach volumes to/from a resized server. Because of"},{"line_number":429,"context_line":"   this, mirroring those block device mapping changes from the target cell DB"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_e375eafb","line":426,"in_reply_to":"ffd0ebdf_03c6ee68","updated":"2019-01-03 19:11:45.000000000","message":"I\u0027m not sure I understand the first bit. We start with a migration_context and migration in the source, and then copy those to the target when we get going right? I\u0027m saying when we do that, we write the migration first, get the new id, and then fix the context before we write it out. So we\u0027re never writing data into a db that isn\u0027t internally consistent. Your second bit seems to be closer to this, yeah.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"0f414f70f6671b6d6d57db1cb760b4b1cc37cfdd","unresolved":false,"context_lines":[{"line_number":423,"context_line":"   which may be wrong if the migration context was created in a different cell"},{"line_number":424,"context_line":"   database where the id primary key on the migration record is different."},{"line_number":425,"context_line":"   It is not clear if this will be a problem but that code might need to change"},{"line_number":426,"context_line":"   to use migration uuid rather than id."},{"line_number":427,"context_line":""},{"line_number":428,"context_line":"3. It is possible to attach/detach volumes to/from a resized server. Because of"},{"line_number":429,"context_line":"   this, mirroring those block device mapping changes from the target cell DB"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_5a837705","line":426,"in_reply_to":"ffd0ebdf_0656fc2a","updated":"2019-01-03 23:26:54.000000000","message":"Done","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"e2a3179fb3d54dcd8f2fa5469bd5215a65a2c2ca","unresolved":false,"context_lines":[{"line_number":423,"context_line":"   which may be wrong if the migration context was created in a different cell"},{"line_number":424,"context_line":"   database where the id primary key on the migration record is different."},{"line_number":425,"context_line":"   It is not clear if this will be a problem but that code might need to change"},{"line_number":426,"context_line":"   to use migration uuid rather than id."},{"line_number":427,"context_line":""},{"line_number":428,"context_line":"3. It is possible to attach/detach volumes to/from a resized server. Because of"},{"line_number":429,"context_line":"   this, mirroring those block device mapping changes from the target cell DB"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ffd0ebdf_0656fc2a","line":426,"in_reply_to":"ffd0ebdf_e375eafb","updated":"2019-01-03 20:03:59.000000000","message":"I wasn\u0027t planning on having conductor create the migration context, since the RT.resize_claim in prep_snapshot_based_resize_at_dest (in the target cell) will do that, and then I need to mirror that migration_context from the instance in the target cell DB back to the source cell DB, and I\u0027m saying at that point that I mirror back to the source cell DB, I adjust the migration_context there to match the source DB migration record.\n\nIOW, this is what creates the migration_context today:\n\nhttps://github.com/openstack/nova/blob/8ef3d253a086e4f8575f5221d4515cda421abea2/nova/compute/resource_tracker.py#L336\n\nAnd that happens in the target cell DB for this flow.\n\nI\u0027ll just make a note that when mirroring the migration context back from the target DB to the source DB we\u0027ll fix the MigrationContext.migration_id \u003d source_cell_migration.id (for the source cell).\n\nBut this is kind of why I was saying doing the lookup in the API based on migration UUID sure would be easier.","commit_id":"092ed02fdcee56380c00f413615ab3d17505fb94"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":22,"context_line":"it is common for deployments to shard cells by hardware types, and therefore"},{"line_number":23,"context_line":"flavors isolated to that hardware, the inability to resize across cells is"},{"line_number":24,"context_line":"problematic when a deployment wants to move workloads off the old hardware"},{"line_number":25,"context_line":"(flavors) and onto new hardware."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_9f831557","line":25,"updated":"2019-01-07 10:45:44.000000000","message":"In theory, flavors shouldn\u0027t be related to specific physical hardware but rather abstract ones, but I understand the reason : for example, 1 VCPU amount could be very different between two pCPUs and sometimes you want to have new flavors providing a better performance for 1 VCPU.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b935aef9aa3e178570a5acc718dccd6199578dbe","unresolved":false,"context_lines":[{"line_number":22,"context_line":"it is common for deployments to shard cells by hardware types, and therefore"},{"line_number":23,"context_line":"flavors isolated to that hardware, the inability to resize across cells is"},{"line_number":24,"context_line":"problematic when a deployment wants to move workloads off the old hardware"},{"line_number":25,"context_line":"(flavors) and onto new hardware."},{"line_number":26,"context_line":""},{"line_number":27,"context_line":"Use Cases"},{"line_number":28,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_b9c2b1e8","line":25,"in_reply_to":"dfd5e7cf_9f831557","updated":"2019-01-07 15:27:19.000000000","message":"The purpose for flavors can be different depending on your environment, and there\u0027s certainly a use-case for flavors that map to generations of hardware.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":33,"context_line":"users having to destroy and recreate their workloads."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"As a user, I want to my servers to retain their IPs, volumes and UUID"},{"line_number":36,"context_line":"while being migrated to another cell."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_1f21654e","line":36,"updated":"2019-01-07 10:45:44.000000000","message":"Well, if you\u0027re an user, you don\u0027t know about cells, right?\nThe users would only see available zones (which could be actually cells of course)","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"fc179177ac9972eb7a68536c717fef0445d243b5","unresolved":false,"context_lines":[{"line_number":33,"context_line":"users having to destroy and recreate their workloads."},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"As a user, I want to my servers to retain their IPs, volumes and UUID"},{"line_number":36,"context_line":"while being migrated to another cell."},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"Proposed change"},{"line_number":39,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_3bcc5234","line":36,"in_reply_to":"dfd5e7cf_1f21654e","updated":"2019-01-14 17:04:52.000000000","message":"Yeah this isn\u0027t meant to be about a user knowing about cells. I think Dan mentioned elsewhere, but as a user if the cloud is doing a big migration they could tell me, \"you\u0027ve got 30 days to backup and kill this VM because we need to move it\" which puts the burden on the user to do the migration and hopefully their application is built to handle that.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":60,"context_line":"We are doing resize because cells can be sharded by flavors and resize is the"},{"line_number":61,"context_line":"only non-admin way (by default) for users to opt into migrating from one cell"},{"line_number":62,"context_line":"with an old flavor (gen1) to a new flavor (gen2) in a new cell. This eases up"},{"line_number":63,"context_line":"admins/operators to drain old cells with old hardware."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Terms"},{"line_number":66,"context_line":"-----"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_5f836d05","line":63,"updated":"2019-01-07 10:45:44.000000000","message":"That\u0027s supposing that users know about cells, but okay.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"fc179177ac9972eb7a68536c717fef0445d243b5","unresolved":false,"context_lines":[{"line_number":60,"context_line":"We are doing resize because cells can be sharded by flavors and resize is the"},{"line_number":61,"context_line":"only non-admin way (by default) for users to opt into migrating from one cell"},{"line_number":62,"context_line":"with an old flavor (gen1) to a new flavor (gen2) in a new cell. This eases up"},{"line_number":63,"context_line":"admins/operators to drain old cells with old hardware."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Terms"},{"line_number":66,"context_line":"-----"}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_fbd56aba","line":63,"in_reply_to":"dfd5e7cf_398561ae","updated":"2019-01-14 17:04:52.000000000","message":"Correct yeah, thanks Dan. That\u0027s also what I was trying to say above in the use cases section.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b935aef9aa3e178570a5acc718dccd6199578dbe","unresolved":false,"context_lines":[{"line_number":60,"context_line":"We are doing resize because cells can be sharded by flavors and resize is the"},{"line_number":61,"context_line":"only non-admin way (by default) for users to opt into migrating from one cell"},{"line_number":62,"context_line":"with an old flavor (gen1) to a new flavor (gen2) in a new cell. This eases up"},{"line_number":63,"context_line":"admins/operators to drain old cells with old hardware."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"Terms"},{"line_number":66,"context_line":"-----"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_398561ae","line":63,"in_reply_to":"dfd5e7cf_5f836d05","updated":"2019-01-07 15:27:19.000000000","message":"No, I don\u0027t think that\u0027s what he\u0027s saying here. He\u0027s saying that users, by naturally resizing their instances every once in a while will help with the  migration. If not, the admins can also give them \"new\" flavors and tell them they need to resize their instances by a certain date. By having this be doable by a user-controlled process, the users can help with the migration without knowing anything about cells underneath.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":84,"context_line":"Assumptions"},{"line_number":85,"context_line":"-----------"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"* There is no SSH access between compute hosts in different cells."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The image service (glance), persistent volume storage (cinder) and tenant"},{"line_number":90,"context_line":"  networks (neutron) span cells."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_9fb795d9","line":87,"updated":"2019-01-07 10:45:44.000000000","message":"I\u0027d rather turn the bullet point into saying \"no connectivity between cells, except X or Y\" so operators looking at this spec shall know exactly what\u0027s needed in terms of cross-cell connectivity.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b935aef9aa3e178570a5acc718dccd6199578dbe","unresolved":false,"context_lines":[{"line_number":84,"context_line":"Assumptions"},{"line_number":85,"context_line":"-----------"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"* There is no SSH access between compute hosts in different cells."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The image service (glance), persistent volume storage (cinder) and tenant"},{"line_number":90,"context_line":"  networks (neutron) span cells."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_d97f75a9","line":87,"in_reply_to":"dfd5e7cf_9fb795d9","updated":"2019-01-07 15:27:19.000000000","message":"I assume you mean make this more generic by removing \"SSH\" and just talking about the lack of connectivity between compute nodes that regular resize relies on, right?","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"db80c00ec73959ac26435bf4018580074a75d3ac","unresolved":false,"context_lines":[{"line_number":84,"context_line":"Assumptions"},{"line_number":85,"context_line":"-----------"},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"* There is no SSH access between compute hosts in different cells."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* The image service (glance), persistent volume storage (cinder) and tenant"},{"line_number":90,"context_line":"  networks (neutron) span cells."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_6821d0b4","line":87,"in_reply_to":"dfd5e7cf_d97f75a9","updated":"2019-01-07 16:54:04.000000000","message":"Correct.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":106,"context_line":"compatible and flexible so that operators can determine which users in their"},{"line_number":107,"context_line":"cloud are allowed to perform a cross-cell resize. For example, it probably"},{"line_number":108,"context_line":"makes sense for operators to allow only system-level admins or test engineers"},{"line_number":109,"context_line":"to perform a cross-cell resize initially."},{"line_number":110,"context_line":""},{"line_number":111,"context_line":"Resize flow"},{"line_number":112,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_9f8eb525","line":109,"updated":"2019-01-07 10:45:44.000000000","message":"++","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":167,"context_line":""},{"line_number":168,"context_line":"The ``MigrationTask`` will check the selected destinations from the scheduler"},{"line_number":169,"context_line":"to see if they are in another cell and if so, call off to a new set of"},{"line_number":170,"context_line":"conductor tasks to orchestrate the cross-cell resize. Conductor will set"},{"line_number":171,"context_line":"``Migration.cross_cell_move\u003dTrue`` which will be used in the API to control"},{"line_number":172,"context_line":"confirm/revert logic."},{"line_number":173,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_bf1859d3","line":170,"range":{"start_line":170,"start_character":64,"end_line":170,"end_character":72},"updated":"2019-01-07 10:45:44.000000000","message":"will set what exactly ? I assume this is a new object field when I look at the DB impact below.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"db80c00ec73959ac26435bf4018580074a75d3ac","unresolved":false,"context_lines":[{"line_number":167,"context_line":""},{"line_number":168,"context_line":"The ``MigrationTask`` will check the selected destinations from the scheduler"},{"line_number":169,"context_line":"to see if they are in another cell and if so, call off to a new set of"},{"line_number":170,"context_line":"conductor tasks to orchestrate the cross-cell resize. Conductor will set"},{"line_number":171,"context_line":"``Migration.cross_cell_move\u003dTrue`` which will be used in the API to control"},{"line_number":172,"context_line":"confirm/revert logic."},{"line_number":173,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_8813d466","line":170,"range":{"start_line":170,"start_character":64,"end_line":170,"end_character":72},"in_reply_to":"dfd5e7cf_794a0981","updated":"2019-01-07 16:54:04.000000000","message":"Well, it doesn\u0027t explicitely say that the o.vo Migration object will have a new field defaulted to False, but meh :-)","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"fc179177ac9972eb7a68536c717fef0445d243b5","unresolved":false,"context_lines":[{"line_number":167,"context_line":""},{"line_number":168,"context_line":"The ``MigrationTask`` will check the selected destinations from the scheduler"},{"line_number":169,"context_line":"to see if they are in another cell and if so, call off to a new set of"},{"line_number":170,"context_line":"conductor tasks to orchestrate the cross-cell resize. Conductor will set"},{"line_number":171,"context_line":"``Migration.cross_cell_move\u003dTrue`` which will be used in the API to control"},{"line_number":172,"context_line":"confirm/revert logic."},{"line_number":173,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_dbe98680","line":170,"range":{"start_line":170,"start_character":64,"end_line":170,"end_character":72},"in_reply_to":"dfd5e7cf_8813d466","updated":"2019-01-14 17:04:52.000000000","message":"Those details are in the data model impact section below.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b935aef9aa3e178570a5acc718dccd6199578dbe","unresolved":false,"context_lines":[{"line_number":167,"context_line":""},{"line_number":168,"context_line":"The ``MigrationTask`` will check the selected destinations from the scheduler"},{"line_number":169,"context_line":"to see if they are in another cell and if so, call off to a new set of"},{"line_number":170,"context_line":"conductor tasks to orchestrate the cross-cell resize. Conductor will set"},{"line_number":171,"context_line":"``Migration.cross_cell_move\u003dTrue`` which will be used in the API to control"},{"line_number":172,"context_line":"confirm/revert logic."},{"line_number":173,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_794a0981","line":170,"range":{"start_line":170,"start_character":64,"end_line":170,"end_character":72},"in_reply_to":"dfd5e7cf_bf1859d3","updated":"2019-01-07 15:27:19.000000000","message":"The next line continues to say exactly what field, and to what value :)","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":182,"context_line":"block device mappings, network info cache, instance actions, etc."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"In order to hide the target cell instance from the API when listing servers,"},{"line_number":185,"context_line":"the instance in the target cell will be created with a ``hidden\u003dTrue`` field"},{"line_number":186,"context_line":"which will be used to filter out these types of instances from the API."},{"line_number":187,"context_line":"Remember that at this point, the instance mapping in the API points at the"},{"line_number":188,"context_line":"source cell, so ``GET /servers/{server_id}`` would still only show details"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_ff7ca1b6","line":185,"range":{"start_line":185,"start_character":55,"end_line":185,"end_character":76},"updated":"2019-01-07 10:45:44.000000000","message":"I\u0027m not super happy with at least the naming of this field, which could be very confusing in the future. I also try to consider alternative approaches for preventing us to add yet another field in the Instance object for a very specifically oriented usecase.\nFor example, an alternative could be to consider having duplicate instance record in both cells to be perfectly fine, and just to a deduplication on the API method for listing all servers. That would be way less invasive and error-prone (you need to care about the state change in the DB)","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"991f43b9aa355eed1ab18dc02ebfd949f22df027","unresolved":false,"context_lines":[{"line_number":182,"context_line":"block device mappings, network info cache, instance actions, etc."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"In order to hide the target cell instance from the API when listing servers,"},{"line_number":185,"context_line":"the instance in the target cell will be created with a ``hidden\u003dTrue`` field"},{"line_number":186,"context_line":"which will be used to filter out these types of instances from the API."},{"line_number":187,"context_line":"Remember that at this point, the instance mapping in the API points at the"},{"line_number":188,"context_line":"source cell, so ``GET /servers/{server_id}`` would still only show details"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_3924810d","line":185,"range":{"start_line":185,"start_character":55,"end_line":185,"end_character":76},"in_reply_to":"dfd5e7cf_333d82bb","updated":"2019-01-07 15:17:30.000000000","message":"We could call it \"admin_hidden\" or \"system_hidden\" or something like that. I\u0027m hesitant to name it something related to resizing because it could be used for other things.\n\nDe-duping in the API is not an option, IMHO, because we can\u0027t iterate all the results without un-doing a bunch of the cross-cell listing performance gains we\u0027ve made recently (not to mention it\u0027s a bad idea in general). We do a fast de-dupe right now by just keeping track of every uuid we\u0027ve returned and filtering out any we come across a second time, but that of course only works if you\u0027re lucky enough to hit the one you want to keep first.\n\nI don\u0027t think there\u0027s any good-performing option other than marking the instance in some way. We could add a new task-state or vm-state if that makes you feel better, although we have to make sure anything else that handles those knows what to do if such an instance is encountered.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"393c10bcb2b15399a93534d74d50278296232aae","unresolved":false,"context_lines":[{"line_number":182,"context_line":"block device mappings, network info cache, instance actions, etc."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"In order to hide the target cell instance from the API when listing servers,"},{"line_number":185,"context_line":"the instance in the target cell will be created with a ``hidden\u003dTrue`` field"},{"line_number":186,"context_line":"which will be used to filter out these types of instances from the API."},{"line_number":187,"context_line":"Remember that at this point, the instance mapping in the API points at the"},{"line_number":188,"context_line":"source cell, so ``GET /servers/{server_id}`` would still only show details"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_b9507134","line":185,"range":{"start_line":185,"start_character":55,"end_line":185,"end_character":76},"in_reply_to":"dfd5e7cf_3924810d","updated":"2019-01-07 15:25:51.000000000","message":"\u003e We could call it \"admin_hidden\" or \"system_hidden\" or something\n \u003e like that. I\u0027m hesitant to name it something related to resizing\n \u003e because it could be used for other things.\n \u003e \n\nAnyway, I don\u0027t want to nitpick on names. I just want to make sure we understand *why* we need a new field, and why not we can\u0027t just dedup in the API but you replied below :\n\n \u003e De-duping in the API is not an option, IMHO, because we can\u0027t\n \u003e iterate all the results without un-doing a bunch of the cross-cell\n \u003e listing performance gains we\u0027ve made recently (not to mention it\u0027s\n \u003e a bad idea in general). We do a fast de-dupe right now by just\n \u003e keeping track of every uuid we\u0027ve returned and filtering out any we\n \u003e come across a second time, but that of course only works if you\u0027re\n \u003e lucky enough to hit the one you want to keep first.\n \u003e \n\nAh-ha, good point. Well, if you feel that\u0027s important, then OK, we can maybe discuss this again during the implementation review.\n\n \u003e I don\u0027t think there\u0027s any good-performing option other than marking\n \u003e the instance in some way. We could add a new task-state or vm-state\n \u003e if that makes you feel better, although we have to make sure\n \u003e anything else that handles those knows what to do if such an\n \u003e instance is encountered.\n\nYeah, I understand your concern. Given that\u0027s not something we can discuss here, but rather in the direct modifications, I\u0027m fine with accepting the proposal now, and see whether it\u0027s the right way or not during the implementation.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4344d0b3af73ab83b10fa6e2d4ffcf1cf916ded7","unresolved":false,"context_lines":[{"line_number":182,"context_line":"block device mappings, network info cache, instance actions, etc."},{"line_number":183,"context_line":""},{"line_number":184,"context_line":"In order to hide the target cell instance from the API when listing servers,"},{"line_number":185,"context_line":"the instance in the target cell will be created with a ``hidden\u003dTrue`` field"},{"line_number":186,"context_line":"which will be used to filter out these types of instances from the API."},{"line_number":187,"context_line":"Remember that at this point, the instance mapping in the API points at the"},{"line_number":188,"context_line":"source cell, so ``GET /servers/{server_id}`` would still only show details"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_333d82bb","line":185,"range":{"start_line":185,"start_character":55,"end_line":185,"end_character":76},"in_reply_to":"dfd5e7cf_ff7ca1b6","updated":"2019-01-07 13:39:05.000000000","message":"The API already dedupes but you might not get the correct instance in the results. Alternative to this we could lookup the instance mapping if we get a dupe while listing to choose which to show but that could impact performance if you have several of these or if you have dupes because of build requests at the same time. Dan also suggested we delete from the source cell during the resize and read from deleted if we need to modify that instance but I think that might have a lot of unknown side effects. So we hve options but none are great, and as you said this is an implementation detail.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"827ce13e571f8c630d72490e3c7591896977cd68","unresolved":false,"context_lines":[{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* Power off the instance."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"* For non-volume-backed instances, create and upload a snapshot image of the"},{"line_number":233,"context_line":"  root disk. Like shelve, this snapshot image will be used temporarily during"},{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_e43177ee","line":233,"range":{"start_line":232,"start_character":35,"end_line":233,"end_character":45},"updated":"2019-01-07 07:53:25.000000000","message":"So who will this snapshot belong to? I mean will there be a case that the quota for this user is used up so he cannot do cross-cell resize? or it will belong to admin or a migration?","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"4e1c7cf7eca782f18122056d1e05680341a3da72","unresolved":false,"context_lines":[{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* Power off the instance."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"* For non-volume-backed instances, create and upload a snapshot image of the"},{"line_number":233,"context_line":"  root disk. Like shelve, this snapshot image will be used temporarily during"},{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_b1bb7ac2","line":233,"range":{"start_line":232,"start_character":35,"end_line":233,"end_character":45},"in_reply_to":"bfdaf3ff_28516363","updated":"2019-01-15 01:55:10.000000000","message":"So I guess what you mean here is that, your patch will fix the case (2) you mentioned, and as you mentioned in case (1), if admin triggers resize, the snapthot quota should probably be unlimited. But still, when a normal user triggers cross-cell resieze, it might fail due to quota limit, right?","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"4528b80989ad95bc7f2eeeb06f74dad2199128a3","unresolved":false,"context_lines":[{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* Power off the instance."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"* For non-volume-backed instances, create and upload a snapshot image of the"},{"line_number":233,"context_line":"  root disk. Like shelve, this snapshot image will be used temporarily during"},{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_142a698f","line":233,"range":{"start_line":232,"start_character":35,"end_line":233,"end_character":45},"in_reply_to":"bfdaf3ff_545b1153","updated":"2019-01-15 14:19:25.000000000","message":"*so snapshots should *not* just pile up in glance taking up quota","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"9b7ff8732c1f8087897357f504d50c6ebfe047ed","unresolved":false,"context_lines":[{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* Power off the instance."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"* For non-volume-backed instances, create and upload a snapshot image of the"},{"line_number":233,"context_line":"  root disk. Like shelve, this snapshot image will be used temporarily during"},{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_545b1153","line":233,"range":{"start_line":232,"start_character":35,"end_line":233,"end_character":45},"in_reply_to":"bfdaf3ff_b1bb7ac2","updated":"2019-01-15 14:18:32.000000000","message":"\u003e But still, when a normal user triggers cross-cell resieze, it might fail due to quota limit, right?\n\nYes, but like shelve, the snapshot image is only temporary and nova automatically deletes it, so snapshots should just pile up in glance taking up quota for the user. Otherwise I\u0027ve never heard of image quota being an issue for tenants - is that a real concern in some clouds, e.g. Huawei cloud?","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"80a0a137133bf989da28bfc3ad568a5295c6378a","unresolved":false,"context_lines":[{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* Power off the instance."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"* For non-volume-backed instances, create and upload a snapshot image of the"},{"line_number":233,"context_line":"  root disk. Like shelve, this snapshot image will be used temporarily during"},{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_28516363","line":233,"range":{"start_line":232,"start_character":35,"end_line":233,"end_character":45},"in_reply_to":"bfdaf3ff_fea9d8de","updated":"2019-01-14 22:34:48.000000000","message":"FYI, I have a fix for this bug here:\n\nhttps://review.openstack.org/#/c/630769/","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"fc179177ac9972eb7a68536c717fef0445d243b5","unresolved":false,"context_lines":[{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* Power off the instance."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"* For non-volume-backed instances, create and upload a snapshot image of the"},{"line_number":233,"context_line":"  root disk. Like shelve, this snapshot image will be used temporarily during"},{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_fea9d8de","line":233,"range":{"start_line":232,"start_character":35,"end_line":233,"end_character":45},"in_reply_to":"dfd5e7cf_7f4af180","updated":"2019-01-14 17:04:52.000000000","message":"The code in the API today sets the user_id image property to the context user_id:\n\nhttps://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/compute/api.py#L2991\n\nLooking at the image service API reference, user_id isn\u0027t listed as a \"base\" property:\n\nhttps://developer.openstack.org/api-ref/image/v2/index.html?expanded\u003dshow-image-detail#show-image\n\nThe compute API also makes it a private image:\n\nhttps://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/compute/api.py#L3020\n\nhttps://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/image/glance.py#L758\n\nI don\u0027t actually see the \u0027owner\u0027 property set on the image:\n\nhttps://github.com/openstack/nova/blob/da98f4ba4554139b3901103aa0d26876b11e1d9a/nova/image/glance.py#L536\n\nSo I\u0027m assuming the image, by default, is owned by the tenant of the current request context, which could be an admin (not the actual owner of the instance) if doing a resize or cold migration on behalf of the user. This is a known issue for shelve/unshelve, see bug 1675791.\n\nBrin Zhang also has a related spec for the normal snapshot case where the admin creates the snapshot but the user can\u0027t use it:\n\nhttps://review.openstack.org/#/c/616843/\n\nI believe the solution would be similar as to what I proposed in bug 1675791 where the admin tenant can \"own\" the image but also share it with the owner of the instance (the user):\n\nhttps://developer.openstack.org/api-ref/image/v2/index.html#image-sharing\n\nIt looks like adding an image member of the user to the image would solve the problem. By default, the image member status is \u0027pending\u0027 which means the user (member) can \"show\" the image directly with the ID but it won\u0027t show up when listing images by default.\n\nAnyway, this is likely only a problem in the case of (1) quota (wouldn\u0027t an admin have unlimited quota?) or (2) the admin resizes the instance and then the user can\u0027t verify/reject it because they don\u0027t have access to the image - this is the bug which can be fixed with image membership changes as noted, or the admin can verify/reject the resize.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* Power off the instance."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"* For non-volume-backed instances, create and upload a snapshot image of the"},{"line_number":233,"context_line":"  root disk. Like shelve, this snapshot image will be used temporarily during"},{"line_number":234,"context_line":"  the resize and upon successful completion will be deleted. The old/new"},{"line_number":235,"context_line":"  image_ref will be stored in the migration_context."},{"line_number":236,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_7f4af180","line":233,"range":{"start_line":232,"start_character":35,"end_line":233,"end_character":45},"in_reply_to":"dfd5e7cf_e43177ee","updated":"2019-01-07 10:45:44.000000000","message":"That\u0027s a valid concern, but I feel we can discuss this on the implemenation phase.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":317,"context_line":"------------"},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":320,"context_line":"is True, the API will:"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"* RPC call to the source compute to destroy the guest (including disks)"},{"line_number":323,"context_line":"  similar to the ``driver.confirm_migration`` method and drop the move claim"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_5f3a8de7","line":320,"updated":"2019-01-07 10:45:44.000000000","message":"I\u0027m still unclear on how you do the check, in particular if the instance is pretty old and pre-Stein. I assume, by reading the above, that this field is on the migration object, which ensures to be recent enough to include this field (since the record is created when the migration starts)","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b935aef9aa3e178570a5acc718dccd6199578dbe","unresolved":false,"context_lines":[{"line_number":317,"context_line":"------------"},{"line_number":318,"context_line":""},{"line_number":319,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":320,"context_line":"is True, the API will:"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"* RPC call to the source compute to destroy the guest (including disks)"},{"line_number":323,"context_line":"  similar to the ``driver.confirm_migration`` method and drop the move claim"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_b935d1f9","line":320,"in_reply_to":"dfd5e7cf_5f3a8de7","updated":"2019-01-07 15:27:19.000000000","message":"The migration object will get a new field, default to false. If we find that the scheduler has picked a host in a different cell, we will set this to true when we create the migration object so that the rest of the processes (including confirm) will know that we\u0027re moving cells.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9a56846f57ce66ef7398663b17906505e9ec937d","unresolved":false,"context_lines":[{"line_number":319,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":320,"context_line":"is True, the API will:"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"* RPC call to the source compute to destroy the guest (including disks)"},{"line_number":323,"context_line":"  similar to the ``driver.confirm_migration`` method and drop the move claim"},{"line_number":324,"context_line":"  (free up tracked resource usage for the source node)."},{"line_number":325,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffd0ebdf_17337aad","line":322,"updated":"2019-01-04 15:31:43.000000000","message":"The guest will already be gone because we called destroy, right? So this is just cleanup disks and drop the claim, etc?","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"bd30f28c1bf201af5c67d943c5788545ab7726eb","unresolved":false,"context_lines":[{"line_number":319,"context_line":"When confirming a resized server, if the ``Migration.cross_cell_move`` value"},{"line_number":320,"context_line":"is True, the API will:"},{"line_number":321,"context_line":""},{"line_number":322,"context_line":"* RPC call to the source compute to destroy the guest (including disks)"},{"line_number":323,"context_line":"  similar to the ``driver.confirm_migration`` method and drop the move claim"},{"line_number":324,"context_line":"  (free up tracked resource usage for the source node)."},{"line_number":325,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"ffd0ebdf_a294aa8c","line":322,"in_reply_to":"ffd0ebdf_17337aad","updated":"2019-01-04 16:00:14.000000000","message":"Correct.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":15888,"name":"Zhenyu Zheng","email":"zheng.zhenyu@outlook.com","username":"Kevin_Zheng"},"change_message_id":"827ce13e571f8c630d72490e3c7591896977cd68","unresolved":false,"context_lines":[{"line_number":361,"context_line":"  before spawning in the source cell so that the ``network-vif-plugged``"},{"line_number":362,"context_line":"  event from neutron is routed properly."},{"line_number":363,"context_line":""},{"line_number":364,"context_line":"* Mark the target cell DB instance as ``hidden\u003dTrue`` to hide it from the API"},{"line_number":365,"context_line":"  while listing servers as we revert."},{"line_number":366,"context_line":""},{"line_number":367,"context_line":"* RPC call the dest compute to terminate the instance (destroy the guest,"},{"line_number":368,"context_line":"  disconnect volumes and ports, free up tracked resources)."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_69180081","line":365,"range":{"start_line":364,"start_character":2,"end_line":365,"end_character":37},"updated":"2019-01-07 07:53:25.000000000","message":"I guess you forget to mention the step of marking instance.hidden to False in source cell DB, and it should be before this step","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"57ea94ceb514961655f1b9465ef0a5ab0647081a","unresolved":false,"context_lines":[{"line_number":361,"context_line":"  before spawning in the source cell so that the ``network-vif-plugged``"},{"line_number":362,"context_line":"  event from neutron is routed properly."},{"line_number":363,"context_line":""},{"line_number":364,"context_line":"* Mark the target cell DB instance as ``hidden\u003dTrue`` to hide it from the API"},{"line_number":365,"context_line":"  while listing servers as we revert."},{"line_number":366,"context_line":""},{"line_number":367,"context_line":"* RPC call the dest compute to terminate the instance (destroy the guest,"},{"line_number":368,"context_line":"  disconnect volumes and ports, free up tracked resources)."}],"source_content_type":"text/x-rst","patch_set":3,"id":"dfd5e7cf_7f18b180","line":365,"range":{"start_line":364,"start_character":2,"end_line":365,"end_character":37},"in_reply_to":"dfd5e7cf_69180081","updated":"2019-01-07 10:45:44.000000000","message":"That\u0027s one example of the potential errors we can lead up if we have to manage an extra field on the instance record.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"fc179177ac9972eb7a68536c717fef0445d243b5","unresolved":false,"context_lines":[{"line_number":361,"context_line":"  before spawning in the source cell so that the ``network-vif-plugged``"},{"line_number":362,"context_line":"  event from neutron is routed properly."},{"line_number":363,"context_line":""},{"line_number":364,"context_line":"* Mark the target cell DB instance as ``hidden\u003dTrue`` to hide it from the API"},{"line_number":365,"context_line":"  while listing servers as we revert."},{"line_number":366,"context_line":""},{"line_number":367,"context_line":"* RPC call the dest compute to terminate the instance (destroy the guest,"},{"line_number":368,"context_line":"  disconnect volumes and ports, free up tracked resources)."}],"source_content_type":"text/x-rst","patch_set":3,"id":"bfdaf3ff_7e8e4879","line":365,"range":{"start_line":364,"start_character":2,"end_line":365,"end_character":37},"in_reply_to":"dfd5e7cf_69180081","updated":"2019-01-14 17:04:52.000000000","message":"Yeah good catch.","commit_id":"c604f43b12358ebd2d632431c234069c4f62d930"}]}