)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"78fc64d2_a6b70025","updated":"2026-10-08 13:03:22.000000000","message":"A bunch of good discussions inline. I\u0027m happy with the high level direction.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"30718612d1ffd3c068dcb5e49844db55e35f3233","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"23a04c22_f45fc5fc","updated":"2026-09-30 15:20:06.000000000","message":"Note to reviewers: this is not quite final form yet. Several of the things in the work items list are still things I want to bake into the spec itself. I also have some unanswered questions and a few answered ones I still need to update the text to reflect. But we\u0027re getting close to PTG so I want something linkable for preparing for those discussions.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"ec4ecc10_831e9bc8","updated":"2026-10-08 14:23:45.000000000","message":"Thanks for all the feedback I\u0027ll try to get as much of this integrated as I can and another version up before next week.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ec5ad31ba3d94d578d3a44c91c4429d35b06ddd3","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2205a983_c717b331","updated":"2026-10-05 16:12:07.000000000","message":"sorry i still need to read thihs fully again\ndan are you plannign a revision of this before the ptg i.e. later this week?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"858c5b26_10cc1819","updated":"2026-10-05 14:23:55.000000000","message":"this sounds very promising but I have a few concerns about how we persist the transient information of a running live-migration and about the configuration knobs for cross-cell live-migrations.\nI\u0027m also a bit afraid about the scope of that spec, and I\u0027d like see a clear iterative path about it. I honestly haven\u0027t yet thought about all the upgrade concerns, this will come later (but hopefully the existing machinery I\u0027ve read is mostly additive so those concerns shouldn\u0027t be a lot)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"edc59686f8f5bfcf4da66489d3d16ac699a7ffa1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"44057672_affbafce","in_reply_to":"2205a983_c717b331","updated":"2026-10-05 16:27:45.000000000","message":"Yes, I\u0027ll go through and try to add some more text to address some of the comments, but I think getting the PoC code up and having a high-bandwidth conversation is probably going to provide the most benefit.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06c07215266e4e68e1b5d1532f6dd4f192b50c1c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"9b28df18_8440dc16","in_reply_to":"858c5b26_10cc1819","updated":"2026-10-05 15:41:32.000000000","message":"Well, to me the major point of making iterative progress is just calling this a V2 API, not touching V1 for the moment, and deprecating the latter after we\u0027ve proved this covers all the bases and inspires trust :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"bec32e82e810faa7e420b0227afd0df94e20ca7d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ab99e8a6_3b3ae70a","updated":"2026-10-13 19:16:27.000000000","message":"I really really had hard time to read the current comments :) I tried to reply in right place but i can be wrong. And I have not written the full spec especially AZ support in old vs new API discussion. Overall:\n\n- I think doing it as a new API operation is better idea\n- how we will deprecate/remove the old API can be decided later, we have done same for many APIs like certificate/file injection/nova-network APIs, console APIs etc","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"101a9c34b304a891f64e817c03dcefe709e7dfad","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ac8abb06_8f5526cd","updated":"2026-10-13 10:24:58.000000000","message":"I responded in some of the threads will continue adding my responses later...","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6f2885410f23dd57435224c86d4243dab9df10db","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"48bde2d7_00205224","updated":"2026-10-15 19:23:47.000000000","message":"I\u0027m going to push up another rev here to reflect what we discussed at the PTG. I\u0027m resolving a few obvious comments, but there are so many overlapping things and some which became unresolved from the last round that I don\u0027t want to squash anything out that still needs visibility. So I ask commenters to please resolve whatever of there comments no longer need discussion.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"7f50c42c229cfd88283e9b350fe729d7d7f66174","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"a3703331_ee1a3211","updated":"2026-10-09 11:21:36.000000000","message":"PS","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"b460bd922e6c2320eda27d7b82809fdfb79267e9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"857cef2e_f60c8099","updated":"2026-10-14 13:00:33.000000000","message":"couple of further responses to threads I missed yesterday.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"0a748752_edc1bdb7","updated":"2026-10-08 19:45:22.000000000","message":"gerrit hid all of your and stephsn cpmemnt on v1 i have started reviewign v2 after i pushed my prevsis set of comment and now i see all of the other coments so i am gong to stop fo tody.\n\nand start fresh tomorrow","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"800dfd3a_ebf60fab","updated":"2026-10-09 08:29:36.000000000","message":"this is already becoming a talkative spec, so let me just provide my thoughts","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a0b37dfa16efa64208bf5798ccb1ebd0045f6ebf","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"d9b20d30_e6c423de","updated":"2026-11-02 18:45:39.000000000","message":"FWIW, given there is a very large discussion, I will just provide a summary for PS3 by reproviding my +1 for the existing proposal.\n\n * I\u0027m OK with a new API action as it will propose some experimental feature branch until we can deprecate the legacy API action\n * I don\u0027t want support for floating-AZ move operation as a dependency before this spec as I personally believe this new API action is more important first for testing\n * I like the idea to continue to have support for the existing legacy API action","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"68fcc256d771013fd65c4ac2d3e1123475607705","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"5f65620a_165e38cf","updated":"2026-10-21 01:31:32.000000000","message":"I am good on the direction from API/new v2 version perspective. I have not read the full spec so keeping my vote scope to +1 only. One question inline about pinned instance migration.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6080756f46e9a1f5f51b3c55a2d62852ae4690b7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"6a2bdf1d_8ba2480d","updated":"2026-10-20 14:20:45.000000000","message":"I feel pretty close to +2 on this. I have one design question left inline about the consumer type value.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"82eb634e2e1c7f716e43421159c70a3cb1895e0a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"61bd2641_e4ddf8f7","updated":"2026-10-29 19:48:57.000000000","message":"My humble request is to take a practical approach and implement \u0027use cases\u0027 case by case, rather than pursuing the ideal approach, which carries greater risk.\n\nEither we can make \u0027our APIs THE BEST in the world, with the risk of breaking users\u0027 OR \u0027Try to keep things less-best (or sometimes bad) to give less pain/regression to users\u0027.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"1a469b6f99a5849c278284756291734fb0994f8d","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"928bcc83_0b41412c","updated":"2026-10-29 20:30:56.000000000","message":"My understanding may be incomplete, but this proposal seems reasonable to me and consistent with the direction we discussed at the PTG.\n\nThe main benefit I see is that we can develop the new migration flow in isolation while keeping the existing path available. That limits the risk of regressions affecting current operations and gives us flexibility on delivery: if we encounter significant difficulties and cannot complete the work this cycle, we can continue into the next without having committed existing users to the new implementation.\n\nIntroducing a new API action may not be the ideal solution, but it looks like a reasonable trade-off. It adds complexity for clients and creates transition work, but I have not yet seen something that makes those challenges unmanageable. My impression is that we have handled similar transitions before.\n\nI also had a preliminary look at the PoC. From what I understood, the implementation and the functional tests give substance to the proposed approach. This was not a thorough code review, but my initial impression is positive. Placement error handling and recovery after partially completed finalization seem like areas that will need particular attention and targeted failure tests before merge.\n\nThis is a particularly important change for this cycle. Given its ambition, effectively a substantial rewrite of live migration, and the short cycle, I strongly support keeping the initial scope as small as possible. The core change is already a significant challenge.\n\nTo help us move forward, I would find it useful to identify the remaining concerns that would make this approach unsafe or impractical, and what would be needed to address them. Where several approaches are viable, I hope we can accept some trade-offs and leave room for incremental improvements.\n\nI may be missing important constraints, so I would welcome clarification on any such blockers.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7783fcf84c7d63ddca0f1cc85cbcce0698f8c92b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"5c0e217d_0af1d8e3","updated":"2026-10-28 13:20:59.000000000","message":"OK. I lost my patience retyping things I typed before. Given the number of open questions I will not +2 this right now (even though I\u0027m OK with the direction) to give space for further discussion and to allow to form a compromise. But I really want to ask for some high bandwidth discussion about the remaining open points as I don\u0027t think the current discussion is converging.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6d8ce3800bb96f2e82af74a2a8547ddb9014d93c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"88452e73_1622283d","updated":"2026-11-03 12:16:30.000000000","message":"Switching my vote to +2 to signal my preference to move forward with this. \nI\u0027m fine to with a majority decision or a PTL decision either.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"1a5fdb1efe7e957b7b07e0b9195d6bd32e3a93c6","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"bfd3d760_48b9babe","updated":"2026-11-02 23:04:46.000000000","message":"Thank you everyone for taking the time to discuss this today. I am disappointed that we were unable to leave the meeting with a consensus, although I think we now have a clearer understanding of the remaining disagreement.\n\nMy impression is that there is no single technical solution that satisfies all concerns. Each option introduces trade-offs and some technical debt, either within Nova or in its consumers. Much of the disagreement seems to be about where we place that cost and how we manage the transition risk.\n\nI remain supportive of the new API action. Despite my confidence in Dan\u0027s work, I think we need to preserve our options if the new implementation takes several cycles to stabilize, requires significant changes through successive iterations, or ultimately proves unsuitable for some existing use cases. My concern with selecting the implementation through a microversion is how we retain the freedom to evolve the legacy API independently during that period. I understand that microversions support iterative changes, but I am not yet convinced that they provide the best boundary for this particular transition.\n\nRegarding V3, I am willing to consider a concrete proposal, but I am concerned that introducing a new major API version under the current time constraints could carry greater risk than the pragmatic compromise of a separate action. Defining its scope, compatibility expectations, client support, and eventual transition would require careful consideration. I would be reluctant to make that broader effort a prerequisite for cross-cell live migration without evidence that it is both necessary and achievable within the time available.\n\nWe also need to move forward. Waiting indefinitely for an option that satisfies everyone has a cost of its own. I believe we should be willing to choose an imperfect but workable approach, document the trade-offs, and revisit it if new evidence warrants doing so.\n\nTo reach a decision, I propose that all Nova cores review and vote on the current proposal, including the new API action. If the core team agrees to this process, I suggest a simple majority of participating cores in an explicit direction vote, separate from Gerrit\u0027s normal review scores, with a clear deadline and enough time for everyone to respond. We would explicitly record the outcome and the remaining objections.\n\nIf we cannot agree to use that process, I am prepared to make a direction decision as Nova PTL, taking the arguments raised here and in the meeting into account, and documenting the reasoning. However, this would not be my preferred approach. As I am not a core reviewer, I am conscious that much of the responsibility for implementing and maintaining that decision would fall on others. I would therefore much rather reach a decision collectively with the core team.\n\nIn either case, this would settle the direction of the spec. It would not waive implementation review, testing, or the readiness requirements for merging the feature.\n\nPlease share whether you are comfortable with this proposed way forward.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"624a388e7131d9073d73ff582e117d26bec9fe51","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"3e44292d_1b0f00b4","updated":"2026-11-03 13:11:05.000000000","message":"switching my vote to -2 to capture that i belive this is not ready to proceed due to the level of disagreemnt within the core team on the direction of the feature not only the impletion details as written\n\nthere are substation open issues and conerns that i do not feel woudl be approate to defer to the implementation and my intiall objects form v1 still have not been adressed.\n\ni will prepare a longer respocne later today once i have time to formulate them","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"22bf484f55d9e07c36c2540543461a19a518d37b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"96a50e45_2e77ddfa","in_reply_to":"928bcc83_0b41412c","updated":"2026-11-02 14:17:02.000000000","message":"\u003e The main benefit I see is that we can develop the new migration flow in isolation while keeping the existing path available. ...\n\u003e \n\u003e Introducing a new API action may not be the ideal solution, but it looks like a reasonable trade-off. ...\n\nHopefully this is clearer by now, but these are two separate things. I don\u0027t think anyone is firmly against developing this as a separate code path and continuing to support the old code path alongside the new one for a time period, nor do I think anyone is arguing against the need for *an* API change to make this visible. The main debate (at least from my perspective) is *how* we expose this at the API level. I don\u0027t think there\u0027s a good argument here for implementing this as a wholly new API action and have a number of arguments against doing so. That\u0027s it. That\u0027s the chief sticking point.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"}],"specs/2027.1/approved/cross-cell-live-migration.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Cross-Cell Live Migration"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cross-cell-live-migration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7ab384e3_3b8c0c5c","line":8,"updated":"2026-10-01 16:26:15.000000000","message":"Answering some of these comments makes me realize that perhaps this is the root of the problem. I started proofing this out over a month ago with the goal of making the existing live migration operation work with multiple cells and thus named this effort the above.\n\nHowever, after doing that (twice actually) and realizing it was not the best approach, I stepped back and decided to propose (and prove out) the approach of rethinking  live migration somewhat fundamentally and making it a new entry point entirely. The new thing I\u0027m proposing here is what I think live migration should look like in the future (full stop, cells or no cells). It\u0027s designed in way that removes a lot of fine-granted communication between the computes and thus makes it work the same for crossing cells (or intra cell) _without_ increasing the number of nodes/services required to make it work.\n\nI always argue against creating the launchpad record ahead of time for this reason, so I\u0027ll claim the win here if people would like me to rename this to something more generic.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Cross-Cell Live Migration"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cross-cell-live-migration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"49d49cb8_0ffca1f9","line":8,"in_reply_to":"004f3c85_20932320","updated":"2026-10-08 17:23:57.000000000","message":"Will leave this name for now.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Cross-Cell Live Migration"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cross-cell-live-migration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8e06ddbb_810a1ed1","line":8,"in_reply_to":"7ab384e3_3b8c0c5c","updated":"2026-10-01 17:23:49.000000000","message":"This became apparent to me as I read through the spec 🙂 Not sure it needs to be renamed though.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Cross-Cell Live Migration"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cross-cell-live-migration"}],"source_content_type":"text/x-rst","patch_set":1,"id":"004f3c85_20932320","line":8,"in_reply_to":"8e06ddbb_810a1ed1","updated":"2026-10-08 13:03:22.000000000","message":"I\u0027m fine with the name of the spec so far. Once we have the bikeshedding event on the name of the new action that might inform us how to name the spec :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Nova does not allow for live migration between cells. While cold migration"},{"line_number":23,"context_line":"(and thus resize) *is* supported, such operations are not ideal for operators"},{"line_number":24,"context_line":"performing maintenance and upgrades because they are disruptive to the"},{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."}],"source_content_type":"text/x-rst","patch_set":1,"id":"d0892b99_9072639e","line":25,"range":{"start_line":22,"start_character":54,"end_line":25,"end_character":27},"updated":"2026-09-30 20:22:09.000000000","message":"we also gate it behind a seperate pai rule that defautl to not allowing anyone including admins to use cross cell cold migrations / resize\n\n\ni think if we are to extend live migration to suprpot cross cell opertions we shoudl be adding a new policy rule for it and i think we shoudl be allowign it for `project-admin or service`\n\nif we are confident enough in the core mecahnics of cross cell resize to extend it to live migration i think we shoudl also promote it to genreal admin aviableity and allow service like watcher to leverage this by default.\n\ni have some more tought on that but if the goal is to reduce the feature delta between deployment choices i think its imporant to normalise the policy so the oepration is allowed by anyone or anything that can normally triger a live migration.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Nova does not allow for live migration between cells. While cold migration"},{"line_number":23,"context_line":"(and thus resize) *is* supported, such operations are not ideal for operators"},{"line_number":24,"context_line":"performing maintenance and upgrades because they are disruptive to the"},{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."}],"source_content_type":"text/x-rst","patch_set":1,"id":"b8b2ac9a_f18b33aa","line":25,"range":{"start_line":22,"start_character":54,"end_line":25,"end_character":27},"in_reply_to":"8a939dd6_a11db3c7","updated":"2026-10-08 14:23:45.000000000","message":"This is basically what we have today in cold migration. If the policy is enabled for you then cold migration can trigger cross-cell cold migration if necessary. So the same for live migration is fine. Perhaps an operator would want to allow real admins to do that, but project admins must stay in their own cell.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Nova does not allow for live migration between cells. While cold migration"},{"line_number":23,"context_line":"(and thus resize) *is* supported, such operations are not ideal for operators"},{"line_number":24,"context_line":"performing maintenance and upgrades because they are disruptive to the"},{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."}],"source_content_type":"text/x-rst","patch_set":1,"id":"c3194175_46d70ff2","line":25,"range":{"start_line":22,"start_character":54,"end_line":25,"end_character":27},"in_reply_to":"b8b2ac9a_f18b33aa","updated":"2026-10-08 17:23:57.000000000","message":"Resolving this with a note about adding a new policy role for crossing cells, like we have for cold migration. The \"or service\" default part is presumably a completely separate change we can discuss for v1, cold, etc.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Nova does not allow for live migration between cells. While cold migration"},{"line_number":23,"context_line":"(and thus resize) *is* supported, such operations are not ideal for operators"},{"line_number":24,"context_line":"performing maintenance and upgrades because they are disruptive to the"},{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."}],"source_content_type":"text/x-rst","patch_set":1,"id":"ccb9348c_1311bae2","line":25,"range":{"start_line":22,"start_character":54,"end_line":25,"end_character":27},"in_reply_to":"b9a7a6c4_e354384b","updated":"2026-10-01 17:23:49.000000000","message":"Agree with not distinguishing between regular and cross-cell and the idea of defaulting the policy the same as the existing os-migrateLive API.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Nova does not allow for live migration between cells. While cold migration"},{"line_number":23,"context_line":"(and thus resize) *is* supported, such operations are not ideal for operators"},{"line_number":24,"context_line":"performing maintenance and upgrades because they are disruptive to the"},{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."}],"source_content_type":"text/x-rst","patch_set":1,"id":"8a939dd6_a11db3c7","line":25,"range":{"start_line":22,"start_character":54,"end_line":25,"end_character":27},"in_reply_to":"ccb9348c_1311bae2","updated":"2026-10-08 13:03:22.000000000","message":"ohh a separate policy for target host being in different cell make sense.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":19,"context_line":"Problem description"},{"line_number":20,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":21,"context_line":""},{"line_number":22,"context_line":"Nova does not allow for live migration between cells. While cold migration"},{"line_number":23,"context_line":"(and thus resize) *is* supported, such operations are not ideal for operators"},{"line_number":24,"context_line":"performing maintenance and upgrades because they are disruptive to the"},{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."}],"source_content_type":"text/x-rst","patch_set":1,"id":"b9a7a6c4_e354384b","line":25,"range":{"start_line":22,"start_character":54,"end_line":25,"end_character":27},"in_reply_to":"d0892b99_9072639e","updated":"2026-10-01 16:26:15.000000000","message":"Well, it\u0027s currently a new migration operation at the API-level, so it\u0027ll have a new policy rule as a result. It\u0027s built to not distinguish between regular and cross-cell migration, whereas the cross-cell cold migration is a wholly different thing with different mechanics and restrictions. I would think we would default the policy of the new op (I\u0027ve been calling os-migrateLiveV2 which I don\u0027t love, but more on that below) to the same as the current one. If we want a policy rule for \"can select destination hosts in a different cell than current\" then that might make sense.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Use Cases"},{"line_number":31,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"51e986d9_e42fbde8","line":28,"updated":"2026-09-30 20:22:09.000000000","message":"yep but as part fo this work i think its imporant that we do not regress any of the live migration supprot for nova feature such as numa,vgpu live migration (medev and vfio vairiant driver), vtpm or sriov hotplug migration for neutron ports, pmem migrations.\n\nwe have spent a very long time trying to burn down the parity gaps for those feature and not support so not supporting the gamit of live migration usescase we have enabled over the last few cycel while extending it to corss cell would make the parity delta untenable in my view.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Use Cases"},{"line_number":31,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b9ecb57d_89a15d47","line":28,"in_reply_to":"51e986d9_e42fbde8","updated":"2026-10-01 16:26:15.000000000","message":"Yep, and after several attempts to bolt this onto the current flow, I decided to take a different approach and build it in parallel. That provides us the ability to not disturb the working v1 (sorry I\u0027ll use this language throughout) flow as we build confidence in v2. Part of what makes v1 stable currently is that we\u0027ve bolted cleanup fixes all over the process for bugs we\u0027ve found, and added plenty of back-and-forth between the computes to exchange new data at whatever layer needs it in the process. That\u0027s also what makes it very very difficult to debug and extend today.\n\nSo yes, I don\u0027t want to disturb the current thing at all, and having tried to make minimal changes to it to support this, I\u0027m proposing we build a new thing with different assumptions in parallel. That provides us an opportunity to rethink some of the things that have been baked into the design we\u0027ve had for 15 years.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Use Cases"},{"line_number":31,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dbac4f53_79d7e3d5","line":28,"in_reply_to":"b9ecb57d_89a15d47","updated":"2026-10-01 17:23:49.000000000","message":"+1 to not disturb existing live migration.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":25,"context_line":"workloads in the instances. Further, the live migration operation has become"},{"line_number":26,"context_line":"quite fragmented and disorganized over the years as new technologies and"},{"line_number":27,"context_line":"approaches have been bolted on, fixes and cleanups inserted into various"},{"line_number":28,"context_line":"places to address issues, etc."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Use Cases"},{"line_number":31,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"765d2c89_fbd53c5c","line":28,"in_reply_to":"dbac4f53_79d7e3d5","updated":"2026-10-08 17:23:57.000000000","message":"I\u0027m going to resolve this because it sounds to me like most of the reviewers are in favor of not disturbing existing live migration by making it support cross-cell. I also think myself, gibi, melwitt at least are in favor of a parallel track to avoid boxing v1 migration in before we\u0027re ready.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":35,"context_line":"ability to migrate workloads around during maintenance operations."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"As a user, I want my operator to be able to perform host-level maintenance or"},{"line_number":38,"context_line":"even cell-by-cell upgrades without having to force my instance to restart for"},{"line_number":39,"context_line":"a cold migration."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"555a5c1c_8a508bcc","line":38,"range":{"start_line":38,"start_character":5,"end_line":38,"end_character":26},"updated":"2026-09-30 20:22:09.000000000","message":"meaning standard n -\u003e n+1 or n -\u003e n+2 upgrages of the compute nodes\n\nwe woudl still requrie all condutors includign the cell conductors and console proxies to first be upgraded to the target release before the computes services within a cell.\n\ni think any other changes to upgrades shoudl be seperate form this spec\n\ndo you intended to add a multi cell greade job with live_migration_back_and_fort\u003dtrue to test this?\n\nwe shoudl enabel and configure corss cell migration in the existing multi-cell job if we proceed with this this cycle btu this obvioly wont work in grenade until 2027.2 so my expecation is greade testing would follow next cycle.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":35,"context_line":"ability to migrate workloads around during maintenance operations."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"As a user, I want my operator to be able to perform host-level maintenance or"},{"line_number":38,"context_line":"even cell-by-cell upgrades without having to force my instance to restart for"},{"line_number":39,"context_line":"a cold migration."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f49ec54f_c9017230","line":38,"range":{"start_line":38,"start_character":5,"end_line":38,"end_character":26},"in_reply_to":"0f5b0d9a_4eafeb21","updated":"2026-10-08 17:23:57.000000000","message":"Resolving this because I don\u0027t think there\u0027s anything to add to the spec and there hasn\u0027t been any further discussion.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":35,"context_line":"ability to migrate workloads around during maintenance operations."},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"As a user, I want my operator to be able to perform host-level maintenance or"},{"line_number":38,"context_line":"even cell-by-cell upgrades without having to force my instance to restart for"},{"line_number":39,"context_line":"a cold migration."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"Proposed change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0f5b0d9a_4eafeb21","line":38,"range":{"start_line":38,"start_character":5,"end_line":38,"end_character":26},"in_reply_to":"555a5c1c_8a508bcc","updated":"2026-10-01 16:26:15.000000000","message":"I\u0027m not proposing anything specific about upgrades here, I\u0027m just using it as an example of a reason why being limited to a single cell for moves right now is problematic. This doesn\u0027t change the need for conductors to be upgraded or any other version mechanics.\n\nWe have customers that deploy a single cell initially and want to grow, but by adding a new cell. If they add 100% extra capacity, but can\u0027t redistribute and that\u0027s a problem.\n\nWe also have customers that want to do batched upgrade of compute nodes (like hardware upgrades) and doing that per-cell fits well with their hardware lifecycle and layout. Yet, they can\u0027t drain one cell before being able to do that maintenance.\n\nWe also have customers that want to use cells for scale, with multiple per site/AZ, but don\u0027t want to have these invisible trip wires that make it impossible to move workloads within that site.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d1166689_382538d7","line":65,"updated":"2026-09-30 20:22:09.000000000","message":"this does not really say \nif you are planing to remove the current compute to compute workflow for intra-cell live migration or if it will duplicate that logic for inter-cell and keep the old compute to compute flow within a cell.\n\ni think we need to have a path to consolidate to a singel flwo regardless of cells if we are going to take on board this complextity but i am not sure it has to happen in one cycle.\n\non a similar tech debth note we require multiple portbinding for cross cell resize and cross cell cold migrate btu we still maintian both code path for same cell resize/migate and we have the fallback for live migration too.\n\n\nwe have long talks about cleanign that up.\n\nso as we did with cross ceel resize im expecting that we will requrie neutron multiple port bindng for cross cell live migrate.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"eaa0476260fd756de4f62dc80a7eb618bd338325","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9ec5d5c3_3dec87fe","line":65,"in_reply_to":"007b004b_755166cf","updated":"2026-10-08 20:14:49.000000000","message":"\u003e a wild idea for the future (feel free to ignore it now)\n\nWouldn\u0027t this mean that we would have v1 and v2 \"forever\" with both being nearly identical? I guess the point is that it would be better than being stuck with the entirety of v1 long term. Still not sure why we wouldn\u0027t be able to just 404 it eventually the way we did with nova-network, if we were truly at the point where v2 is stable and better than v1 in every way.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"85872f09_c8bdf01b","line":65,"in_reply_to":"011b20b1_fcb09477","updated":"2026-10-01 17:23:49.000000000","message":"This aligns with what I recall from numerous dev summit discussions over the years about how we would design live migration if we could start fresh and have the super conductor orchestrate everything. So it is nice it feels familiar in that regard.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ec33cac2_097cef5a","line":65,"in_reply_to":"2ec47029_2390689f","updated":"2026-10-08 17:23:57.000000000","message":"Resolving this with a note in the spec about eventual removal and the suggestions made so far which can be deferred to that point.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f58eb61319697b2ef6aefa8bea0f633323d8e8e1","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"49535233_78f727ef","line":65,"in_reply_to":"42567022_ca84a27c","updated":"2026-10-09 14:02:51.000000000","message":"Melanie said:\n\n\u003e I think I\u0027m not as bothered by this idea as I normally would be due to the fact that live migration is an admin-only API. I consider cloud admins to be sophisticated \"power users\" and I don\u0027t expect them to have much issue with the idea of having another API choice that happens to be a major redesign of live migration. I expect they would be enthusiastic to try it given their years of experience with existing live migration.\n\nThis right here should be engraved in gold at the top :)\n\nAdmins are intimately involved with live migrations, they will very much understand the risk with changing anything here and they will understand why there\u0027s a new thing to call to get the new internal plumbing. I feel pretty sure they\u0027d choose this option over having no fallback to the old one, regressions from previously-fixed issues creep back in, or really anything else.\n\n\u003e My overall feeling is that I think we likely need to apply some pragmatism here considering how brittle and entrenched existing live migration code (and its test coverage) are in Nova.\n\nYep, not disturbing the tests (which are very intimately tied to the v1 plumbing, btw) is part of why I stopped my previous effort. I made a bunch of them work with the v2 plumbing, but kept chasing things in circles trying to make the same test (even with broken-out internals) work for both. I do _not_ want to lose any coverage of what we have today, as it is deep.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e369c28dc67fb23b486b822df2be859ed364c0f6","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"879093a6_a16e4bb6","line":65,"in_reply_to":"49535233_78f727ef","updated":"2026-10-09 15:27:31.000000000","message":"admin may be but driect api access is not the only way this is perceived to be used\n\nfor better or worse outsdie fo teh nova and tempst core team very few people actuly knwo how to use microverion properly. i.e. that software system shoudl use the epxpclity microverion they desire to get the bevhior they expect when talkign to the api.\n\nheat, watcher and horizon i belview all use a single microverion for every call to nova.\n\nso there is no possibelity to choose if you get teh old or new semantics. on a per request basis its a hard cut over to the old or new api semantics.\n\nwhile we could and will eventully fix that in watcher i do not want to expose this choice to end user even admin in horizon or watchre.\n\nthat is why im so instentn that if we have the v2 api it must be production ready for all v1 usescase because the choice for heat,horzon and watcher will be use one of v1 or v2 that it.\n\nby the way im fine wiht haveing a RPC/object level flag and new methods to carry if we want the old or new code path or other internal chagnes so that we can keep the old path fucntional internally but what i do not want to see is that exposed to an admin via a microverson or new api endpoint.\n\ni stongly belive that we shoudl be deiciend the code path we take in the condugre based on the configre policy, existing api veriosn/parmanters and source/destination hosts.\n\nin its current state if we have either a new microverson or api which need a new micrvion anyway we will have to make watcehr use 2.105 for every api call to nova\nsame in heat.\n\nthis is one of the reason i really realy dont want to have any api change reqruied to opt into or out of the new flow\n\nhttps://github.com/openstack/watcher/blob/master/watcher/conf/nova.py#L96-L110\n\nwe have started to unpick that in watcher and i was talking to stephen about posisble levgeraging the sdk to help with that but sayign the caller of the service should now is very problematic.\n\nheat has also made some progress here. ti still uses the max verion by default limived via its cofnig\n\nhttps://opendev.org/openstack/heat/src/commit/1a8e5dabf30b0b0ce56d1310701d49ffefaa42db/heat/engine/clients/microversion_mixin.py#L22-L34\n\nhttps://opendev.org/openstack/heat/src/commit/1a8e5dabf30b0b0ce56d1310701d49ffefaa42db/heat/engine/resources/openstack/nova/keypair.py#L157-L161\n\nso im find with add a live_migrate_v2 rpc method.\nleaking that to the rest api much less so","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"41c79b35d1290e89698c4036fda6583bb53612e5","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e551df26_2deed3cd","line":65,"in_reply_to":"62015bc2_908ad4ae","updated":"2026-10-21 13:12:43.000000000","message":"i think that is an argument to not accpte the impletion until we are sure that risk is not presence.\n\nany argumetn based on \"we dont think this is safe to use\" to me is a reason to not accpte the proposl for this cycle.\n\nif we need to have a way for the implementation to be selected i do not think that should be exposed at the API, that would be more appropriate to expose vai a config opiton.\n\nThis is not the same as the console API or the certificate/file injection cases.\nfile injection was a sub parmatier of the server create not a separate  api endpoint and it was a featrue that only some virt driver supproted.\n\nthe console api is still a pain point for our operators and users\nthe fact you have to know what console type that a admin choose to supprot to use it is a failure of desing\n\nit shoudl have just been a single server action to get the servier consoles connection info like  os-getConsoleOutput is.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"cc74b135551534f0920ed631c2b2751e579f3ac2","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"26319539_f3d70a1a","line":65,"in_reply_to":"70ee4738_a8758890","updated":"2026-10-08 14:18:06.000000000","message":"\u003e a wild idea for the future (feel free to ignore it now)\n\nI came here to say something very similar. I\u0027d appreciate it if we could silo off as much of the v1 code as possible, such that we can `rm -rf` the thing down the line. More on this below.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2ec47029_2390689f","line":65,"in_reply_to":"70ee4738_a8758890","updated":"2026-10-08 14:23:45.000000000","message":"We can\u0027t honor some of the other flags it takes and we can\u0027t (likely reliably) honor the synchronous nature of the early versions. But yes, if we would rather make an attempt to honor it instead of return 409 that would be doable with some constraints. I\u0027m not sure whether I\u0027d rather refuse or lie (like returning 200 when you asked for synchronous but we did async instead), but we can have that discussion later.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ae5307afef82617b7ed40c3b6aabc5a193929b76","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"007b004b_755166cf","line":65,"in_reply_to":"70ee4738_a8758890","updated":"2026-10-08 17:47:34.000000000","message":"for what its worth im -2 on the client havign to knwo if it shoudl ever call v1 or v2 and im not convince we should have a v2 api at all\n\ni think that is something we need to arrive at concenosn on.\n\nto me it woudl be much much more reasonable to raise our min microversion then introduce a parllel api path.\n\nwe have a native mechanism to move to newer semantics as part of the micro-version specification  https://opendev.org/openstack/api-sig/src/branch/master/guidelines/microversion_specification.rst","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"70ee4738_a8758890","line":65,"in_reply_to":"85872f09_c8bdf01b","updated":"2026-10-08 13:03:22.000000000","message":"a wild idea for the future (feel free to ignore it now): Assume we have v2 stable in couple of releases, then we are at the point that it is better in every way that v1 and we want to get rid of v1 (not just the API but actaully most of the implementeation and RPC stuff), we can probably create a bit of logic in the v1 API handler to call the v2 implementation if no cross cell move is requested. So we don\u0027t have to deal with the question of how to remove an API, we can just delete the impl behind it and \"redirect\".","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"101a9c34b304a891f64e817c03dcefe709e7dfad","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"848c39d3_e3ae20d7","line":65,"in_reply_to":"879093a6_a16e4bb6","updated":"2026-10-13 10:24:58.000000000","message":"\u003e so there is no possibelity to choose if you get teh old or new semantics. on a per request basis its a hard cut over to the old or new api semantics.\n\n\nI don\u0027t get it. If 2.105 will introduce a new way to live migrate via a) the current api resource b) via a new api resource. Then if watcher, heat or others want to use the new logic, they need to use 2.105 and as they limit to a single version this means they use 2.105 for every interaction. So I don\u0027t see why a) and b) makes it different for them.\n\n\u003e that is why im so instentn that if we have the v2 api it must be production ready for all v1 usescase because the choice for heat,horzon and watcher will be use one of v1 or v2 that it.\n\nBut what is proposed here is actually helping horizon and heat. Having two separate API resource for live migration (v1 and v2) in 2.105 available to consume makes it possible to the consumer to bumpt to 2.105 and **still have choice** to call v1 or v2.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"bec32e82e810faa7e420b0227afd0df94e20ca7d","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"62015bc2_908ad4ae","line":65,"in_reply_to":"879093a6_a16e4bb6","updated":"2026-10-13 19:16:27.000000000","message":"Considering the risk of breaking existing functionality (what written in \u0027Benefits\u0027 section L89), I think having this as a new API and new code path is a better idea.\n\nI have touched the live migration code path during graceful shutdown and witnessed how complex code/cross-interaction we have in exiting one. I really avoid to change anything there thinking I might break some use case/error path especially. \n\nAs this is admin/project-manager API,  its is action API (i mean interface wise this is not a new API endpoint but a new action in existing API endpoint), and risk to break existing functionality, I agree to do this as a complete separate code path/action API.\n\nAnd we have done this in many cases in past (in little different ways/reason):\n- certificate/file injection. nova-network APIs were gone when neutron network is something we wanted.\n- console APIs when we want to improve the API interfaces. We deprecated old till some microversion and added new interface.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f520e942c7bcddbfa2a96f76731a594f348b250d","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"42567022_ca84a27c","line":65,"in_reply_to":"9ec5d5c3_3dec87fe","updated":"2026-10-08 23:49:03.000000000","message":"\u003e for what its worth im -2 on the client havign to knwo if it shoudl ever call v1 or v2 and im not convince we should have a v2 api at all\n\nI think I\u0027m not _as_ bothered by this idea as I normally would be due to the fact that live migration is an admin-only API. I consider cloud admins to be sophisticated \"power users\" and I don\u0027t expect them to have much issue with the idea of having another API choice that happens to be a major redesign of live migration. I expect they would be enthusiastic to try it given their years of experience with existing live migration.\n\nI guess for new cloud admins though, those who don\u0027t already have experience with Nova, it could be more confusing. So that is a fair point ...\n\n\u003e to me it woudl be much much more reasonable to raise our min microversion then introduce a parllel api path.\n\u003e\n\u003e we have a native mechanism to move to newer semantics as part of the micro-version specification https://opendev.org/openstack/api-sig/src/branch/master/guidelines/microversion_specification.rst\n\nRaising the minimum microversion sounds much more disruptive to me ... that would mean that every client would be locked out of all previous API behavior, for all APIs, just so that we can provide a redesigned live migration API, unless I am misunderstanding?\n\nMy overall feeling is that I think we likely need to apply some pragmatism here considering how brittle and entrenched existing live migration code (and its test coverage) are in Nova.\n\nI don\u0027t take the idea of a new live migration API action lightly and when the idea first met my brain I hated it. But the more I thought about it, the more I am thinking this is a matter of, what is the least disruptive, least painful, least likely-to-break-a-critical-function-in-Nova, way that we could redesign live migration. And making a new separate path seems like the safest path to take, and stability and safety are more important to me than the API elegance.\n\nI\u0027m imagining it as, we will have an ugly v1 and v2 side-by-side to live with for a temporary amount of time (1 year? 2 years?) but v2 will stabilize and when it does, we just 404 the API and delete v1. So part of my focus is on the fact that we end up with one live migration API at the end. As far as I am concerned, there is no intention of keeping two live migration APIs long term.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"82eb634e2e1c7f716e43421159c70a3cb1895e0a","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7b3793fe_161a6d10","line":65,"in_reply_to":"ac0719a8_556f79f6","updated":"2026-10-29 19:48:57.000000000","message":"config-driven APIs are not good, which is hard for users(admin) to switch between.\n\nFrom the console API example, I mean to say that we have done such API design (introducing a new API for the same operation) for other reasons, and here the reason might be different, but it follows an acceptable pattern. When I say \u0027acceptable\u0027, I am confident that it is acceptable by users also (because I have not seen any bug about why you introduced a new API for the console and deprecated the old one).\n\nThinking from the admin perspective also, to gain the cross-cell migration, I do not think they want to take risk of breaking their current live migration. Going with safest path is smart design even that is not best.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"011b20b1_fcb09477","line":65,"in_reply_to":"d1166689_382538d7","updated":"2026-10-01 16:26:15.000000000","message":"\u003e this does not really say \n\u003e if you are planing to remove the current compute to compute workflow for intra-cell live migration or if it will duplicate that logic for inter-cell and keep the old compute to compute flow within a cell.\n\nOkay I thought it was clear that I\u0027m building this in parallel (although refactoring several helpers to share common logic where it makes sense). But I\u0027ll add something to make it clear that (helper refactors aside) the v1 flow remains untouched. And also that I\u0027m expecting this to be \"the way live migration works going forward.\" Meaning, you don\u0027t use this process when you want to cross cells and the other one when you don\u0027t. I want this to be the way live migration works in the future and having built the bolt-onto-existing thing already, I think this will be better than what we have even without the cross-cell consideration.\n\n\u003e i think we need to have a path to consolidate to a singel flwo regardless of cells if we are going to take on board this complextity but i am not sure it has to happen in one cycle.\n\nI have spent a month working on trying to do that and I\u0027ve decided that it is far messier. There are many calls back and forth between the two computes which aren\u0027t possible if they\u0027re in separate cells. If you unroll all of that to the beginning, you eliminate the \"v1 live migration continues to work as long as we want to keep it\" benefit and roughly end up where I think this spec is aiming today, but over many cycles of RPC churn and version bumps.\n\n\u003e so as we did with cross ceel resize im expecting that we will requrie neutron multiple port bindng for cross cell live migrate.\n \nYep, and I\u0027m trying to avoid bringing support for many of those things forward to v2. NUMA information in the live migration path is another example.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7783fcf84c7d63ddca0f1cc85cbcce0698f8c92b","unresolved":true,"context_lines":[{"line_number":62,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"},{"line_number":63,"context_line":"migration task that currently exists. The pre-creation and copying of instance"},{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ac0719a8_556f79f6","line":65,"in_reply_to":"e551df26_2deed3cd","updated":"2026-10-28 13:20:59.000000000","message":"\u003e i think that is an argument to not accpte the impletion until we are sure that risk is not presence.\n\n\u003e any argumetn based on \"we dont think this is safe to use\" to me is a reason to not accpte the proposl for this cycle.\n\nI said this before in this review but I\u0027m happy to repeat myself. We will not know that it is really works for our customer base before they start to use it on the field out there. We will not find the bugs I consider as the \"risk\" here by ourselves while the patches sits in gerrit. We need real word usage to find them. See just how many edge cases bolted on the current code to fix bugs reported from the field. We will have new set of such bugs in the new implementation. I want those bugs to be found but also  not to affect the legacy live migration so our customers can safely switch back to something that they know at least works well enough for their current use cases.\n\nDo you want instead that I tell you I promise it will work well? Is it easier to accept that? :)\n\n\u003e if we need to have a way for the implementation to be selected i do not think that should be exposed at the API, that would be more appropriate to expose vai a config opiton.\n\nI\u0027m feeling like I\u0027m repeating myself here again. But sure. So live migration is an operation that use a lot during imminent failure scenario or during critical WA / cleanup to get out of a problematic, workload effecting escalation. If we need to tell customers to reconfigure the nova deployment just to allow to switch back to a working live migration then we are significantly increasing the timeline, cost and risk of ever using the new implementation and as a result we will not learn about the real bugs in it. \n\nI would like to have a way where the admin can selectively run the new and the old implementation without any operational cost. This way we can recommend the new impl for everybody and if a single migration fails with that, discovering a bug, then for that single call the admin can use the old impl. \n\nIf we go with the config driven api behavior then the customers will switch to the legacy impl at the first trouble and stop testing the new impl.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Because the existing live migration operation has multiple legacy modes of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"54111612_95fd55e0","line":67,"updated":"2026-10-08 13:03:22.000000000","message":"Are we OK declaring this new API unstable, alpha, not yet supported, \u003csome wording indicating: hey this might change\u003e so that we can allow us to iterate on the API as well without too much support burden? One cycle, that is a winter one (in the northern hemisphere) probably not enough to commit to an API so deeply. Or at least I would rather not slow down pushing the first implementation out to users and therefore gathering feedback, just to try to stabilize the API. Lets allow specific API comatibility rules for the new action, please. :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6080756f46e9a1f5f51b3c55a2d62852ae4690b7","unresolved":false,"context_lines":[{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Because the existing live migration operation has multiple legacy modes of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"740d7e63_953781fb","line":67,"in_reply_to":"2c200fc2_54d8382e","updated":"2026-10-20 14:20:45.000000000","message":"OK. I sense that we don\u0027t want to mark this as experimental. Fine by me :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Because the existing live migration operation has multiple legacy modes of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ac17da3e_d690dd76","line":67,"in_reply_to":"54111612_95fd55e0","updated":"2026-10-08 14:23:45.000000000","message":"Well, I don\u0027t know if we need to specifically say it\u0027s alpha really (personally) and I generally don\u0027t like implying that we don\u0027t trust a thing as I think it will be less likely to get soak time. I\u0027d prefer that we say \"we expect this to work except for N known issues and this will be the future -- but we have\u0027t removed the old one yet). Much like other services have had v1/v2 APIs (or parts of APIs), I think the one thing v1/v2 naming gives us is a natural sense of transition, upgrade, replacement and newness.\n\nBut that is just MHO, I\u0027m not seriously opposed to what  you describe.\n\n\u003e Lets allow specific API comatibility rules for the new action, please. :)\n\nI\u0027m not sure what you mean by this statement.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ae5307afef82617b7ed40c3b6aabc5a193929b76","unresolved":true,"context_lines":[{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Because the existing live migration operation has multiple legacy modes of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a5d8ca1a_068d9a8d","line":67,"in_reply_to":"54111612_95fd55e0","updated":"2026-10-08 17:47:34.000000000","message":"in general i am not ok with introducing it unless its production ready with 100% parity with the exciting api as of the most recent change that altered live migratoin semantics.\n\nif its not ready this cycle why woudl we merge the api change.\nwe do not supprot experimatl api in nova today and removed api exstions so this would not really feel compatible with how wever have been evolving the api.\n\nsome service like manila i believe do have experimental apis but with my watcher hat on i woudl not support using an experimental api adn i doubt horizon or heat woudl want to do that either.\n\n\nwe technically have the ablity to declare an edpoint as experimental in keystoen\n\nhttps://opendev.org/openstack/api-sig/src/branch/master/guidelines/discoverability.rst?display\u003dsource#L288\n\nbut to do that we would need to start a new nova v4 or v3 api not just this one action/route.\n\nif we wanted to start a v3/4 api taking the latest sematiocs of the current 2.104 microversion  i woudl be ok with that but i dont like this half mesure.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"101a9c34b304a891f64e817c03dcefe709e7dfad","unresolved":true,"context_lines":[{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Because the existing live migration operation has multiple legacy modes of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fb78b3b_1ae54fda","line":67,"in_reply_to":"a5d8ca1a_068d9a8d","updated":"2026-10-13 10:24:58.000000000","message":"\u003e in general i am not ok with introducing it unless its production ready with 100% parity with the exciting api as of the most recent change that altered live migratoin semantics.\n\nI believe nobody can promise you that the first release of this feature will be 100% parity with the semantics / behavior of the old API. We will try but I\u0027m 100% sure we will fail and there will be facepalm bugs. So If you insist that we only release it if it is 100% right then that signals to me that you don\u0027t want to ship this feature as you ask for impossible things.\n\n\u003e if its not ready this cycle why woudl we merge the api change.\n\nI\u0027m pretty sure this implementation will only be ready **after** it was released, some customer used if for a while, reported facepalm bugs to us that are fixed. So not releasing it is actually preventing us to complete this work in my eyes.\n\n\u003e we do not supprot experimatl api in nova today and removed api exstions so this would not really feel compatible with how wever have been evolving the api.\n\nWe are the decision makers of Nova. So we can together as a team decide that what are the rules. :) So yes we don\u0027t have any experimental APIs today, but nothing blocks us to define one going forward. :) In my head it is as simple as a nice bold text in the API doc for the resource, a release note, and a consistent signalling in future bug reports about this API. Why are we limiting ourselves?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"bec32e82e810faa7e420b0227afd0df94e20ca7d","unresolved":true,"context_lines":[{"line_number":64,"context_line":"records will be important to mirror (code reused where possible) for the new"},{"line_number":65,"context_line":"operation if and when the migration will cross cells."},{"line_number":66,"context_line":""},{"line_number":67,"context_line":"New API operation"},{"line_number":68,"context_line":"~~~~~~~~~~~~~~~~~"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"Because the existing live migration operation has multiple legacy modes of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2c200fc2_54d8382e","line":67,"in_reply_to":"a5d8ca1a_068d9a8d","updated":"2026-10-13 19:16:27.000000000","message":"I do not think we need to state this as a unstable API/operation. If this is tested and working in usual scenario I will say declare it as production ready and of course if bugs comes then we fix them. That is what we do in every API even 10 years old and that is why we have more than 100 microversions. If in any use case, this does not work and we missed/cannot test then user have v1 API to continue performing the live migration. That is one reason I like the separate API idea so that we do not break/stop users to continue doing VM live migration when we have many known bugs to fix in new API.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"cc74b135551534f0920ed631c2b2751e579f3ac2","unresolved":true,"context_lines":[{"line_number":80,"context_line":"   complicating the existing code and allowing the new code to rethink some"},{"line_number":81,"context_line":"   things."},{"line_number":82,"context_line":" - Provides us a path to ultimately deprecate and \"remove\" the old mechanism"},{"line_number":83,"context_line":"   (like we have done when dropping virt drivers, network modesl, etc)"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Drawbacks:"},{"line_number":86,"context_line":" - Adds a new API, requiries some handling in the client, users will need to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"85a45709_f8210513","line":83,"updated":"2026-10-08 14:18:06.000000000","message":"```suggestion\n   (like we have done when dropping virt drivers, network models, etc.)\n```","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":80,"context_line":"   complicating the existing code and allowing the new code to rethink some"},{"line_number":81,"context_line":"   things."},{"line_number":82,"context_line":" - Provides us a path to ultimately deprecate and \"remove\" the old mechanism"},{"line_number":83,"context_line":"   (like we have done when dropping virt drivers, network modesl, etc)"},{"line_number":84,"context_line":""},{"line_number":85,"context_line":"Drawbacks:"},{"line_number":86,"context_line":" - Adds a new API, requiries some handling in the client, users will need to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3b856c49_0136346a","line":83,"in_reply_to":"85a45709_f8210513","updated":"2026-10-08 17:23:57.000000000","message":"Done","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"211edd1e_01eebccd","line":90,"updated":"2026-09-30 20:22:09.000000000","message":"i think the drawbacks outway the beniftis here but ill keep reading and reserve judgemtn but my install reaction si -1 ot a new api but that partly depend on what that end up looking like and how much technical debt it can help solve\n\nmuch of the complxity can be handlede by returnign a 409 conflict if the vms does not meet our stricter requirement for cross cell live migrate.\n\nby the way do you mean a new api microversion or a new api. curelty this say the latter but if its a new api you have not adressed how this impact the exting aboort/force complete api ro how you will list the ongorign migrations.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"99d4093b_a1386c71","line":90,"in_reply_to":"14beeae5_e26b4484","updated":"2026-10-08 14:23:45.000000000","message":"\u003e \u003e migrateToURI3\n\u003e \n\u003e hands down the best signal this is complex enough that we should allow us to iterate the API.\n\nIndeed.\n\n\u003e Maybe os-cell-aware-live-migrate :)\n\nI really don\u0027t want to name it this because I don\u0027t want people to think this is only for crossing cells. And it\u0027s long :)\n\n\u003e Lets allow us to create something in an iterative way while keeping the critical operation working at least as good as today. Also I\u0027m pretty sure we will need more than one cycle to stabilize the new \"ultimate\" API (sorry) so freezing the legacy one is not a good tactical move in my eyes.\n\nI believe we _could_ technically stabilize it in a single cycle, but I (at least) can\u0027t trust it by definition because I define trust as \"many cycles of actual use\".\n\n\u003e I disagree. If I have a cloud that does not use vtpm and gpu but I want to move across cells then the new api that does not support those VM features but support cross cell live migration still be useful for me. Sure lest aim for compatibility with all those VM features. But a missing piece should not prevent us to release something to the world and \n\u003e * i) give a chance for some folks to try it and gave us feedback \n\u003e * ii) give us time to iterate not in a long ass patch series, but in actual codebase, with regular, frequent CI, and the ability to keep our sanity by only keep those parts of the problem in our brains that are open for iteration and not the whole bag.\n\nYep, I don\u0027t want to intentionally create debt for sure. I wouldn\u0027t exclude any of these things until/unless we determine they\u0027re harder and don\u0027t work without trouble. But, I\u0027d rather make progress with this massive effort, especially while we have both paths available. I don\u0027t love that virtiofs landed without even more basic support (like cold migration) but the reality is we might still be iterating on that set if we hadn\u0027t.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ae5307afef82617b7ed40c3b6aabc5a193929b76","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"2215db6c_fa65e393","line":90,"in_reply_to":"14beeae5_e26b4484","updated":"2026-10-08 17:47:34.000000000","message":"we do not need any api change to supprot cross cell live migration\n\nthat does nto need to be visable at the api level at all and in fact we curenly have an unwitten rule that tcells shoudl never be expsed at the api.\n\nas such i would see a cells specific mivration api woudl directly go againce that.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"c1429220_7aa9b50e","line":90,"in_reply_to":"211edd1e_01eebccd","updated":"2026-10-01 16:26:15.000000000","message":"\u003e i think the drawbacks outway the beniftis here but ill keep reading and reserve judgemtn but my install reaction si -1 ot a new api but that partly depend on what that end up looking like and how much technical debt it can help solve\n\nObviously we can just drive the new flow if the microversion is greater than X and the old one if it\u0027s less. If that\u0027s really what people want, then that\u0027s certainly doable. However, I think that splitting them allows us to avoid the case where v1 is frozen in time, we have to support it until we bump the minimum microversion to 1.105ish. If v2 doesn\u0027t inspire confidence in the first cycle and we want to add something like `dest_availability_zone` to v1 in the interim, we\u0027re toast.\n\n\u003e by the way do you mean a new api microversion or a new api. curelty this say the latter but if its a new api you have not adressed how this impact the exting aboort/force complete api ro how you will list the ongorign migrations.\n\nI mean a new API. Fair point on missing coverage here for force/abort, although in practice I don\u0027t think it will be different.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"2b0d992e_2eb170c0","line":90,"in_reply_to":"2215db6c_fa65e393","updated":"2026-10-09 08:29:36.000000000","message":"@dms@danplanet.com I think I got your point, so here is my stance : I\u0027m OK with two different supported endpoints for the time it requires, provided we send clearly the message that the legacy live-migration will eventually be deprecated once we reach feature parity. I don\u0027t particularly care about how this message has to be communicated (code comment, logs, CLI, whatever), I just wanted it to be clearly noted on the spec so we could refer to it if needed.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"bec32e82e810faa7e420b0227afd0df94e20ca7d","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3d6309f6_572b9ff1","line":90,"in_reply_to":"2b0d992e_2eb170c0","updated":"2026-10-13 19:16:27.000000000","message":"\u003e \u003e Maybe os-cell-aware-live-migrate :)\n\n\u003e I really don\u0027t want to name it this because I don\u0027t want people to think this is only for crossing cells. And it\u0027s long :)\n\n\nwe do not need to include \u0027os\u0027 here and maybe just removing that can be a new name: \n\"migrateLive\" or \"liveMigrate\"","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5e032a9258eecad4a9db10a512508d2b23f65c0","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9983572c_9d57980e","line":90,"in_reply_to":"3d6309f6_572b9ff1","updated":"2026-10-13 19:31:06.000000000","message":"\u003e we do not need to include \u0027os\u0027 here and maybe just removing that can be a new name: \n\u003e \"migrateLive\" or \"liveMigrate\"\n\nYeah, you may have inadvertently (or totally on purpose) solved the naming problem here. If we just call it `liveMigrate` then we can amend the api-ref to explain that the \"os\" in `os-migrateLive` actually means \"Old School\" :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"c0865b48_bd8dfe3d","line":90,"in_reply_to":"649e3d69_8b5530cf","updated":"2026-10-05 14:23:55.000000000","message":"I\u0027m honestly very reluctant from creating another API endpoint which would be a fork of another endpoint, which would mean that we would carry on *two* branches for live-migration, but if *at the same time* we call out os-liveMigrate as DEPRECATED, I think I\u0027m OK with it.\n\nTime to bikeshed about the name ?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b36590ab5eefe160787fd020b230d9fa09210aeb","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"efa3ec31_a1dff774","line":90,"in_reply_to":"6d609fb1_bf042118","updated":"2026-10-16 00:58:48.000000000","message":":) that is really good to write in api-ref, os has many meaning and this one is not invalid :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1b8d4f5d56f7cd4cd407ddb0a9a75dd630c9cc10","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"92deb6fb_9b53f532","line":90,"in_reply_to":"71324806_d709ada9","updated":"2026-10-05 16:10:33.000000000","message":"so i dont realy think a new api is viable unless all live migration can use it uncodtionally form day 1\n\nso for watch and horizon to adtop this for example or really even a human\n\ni think they woudl need to be able to use the v2 api for all live migration regardless of the vm resources (vtmp, vgpu, numa, ...) and regardless of\nthe source and destination nodes.\n\nefecitly the new api woudl be just raisign or min microversion for that call when the new ednpoitn is done which im not really sure is preferabel to just bumping the min version in general.\n\ni think 2.25 would get you most of the cleanup you want\n\nhttps://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-mitaka\n\nalthough i woudl actully  prefer 2.38 to pick up 2.34 if we went that rout.\nhttps://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-newton\nhttps://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id31","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"edc59686f8f5bfcf4da66489d3d16ac699a7ffa1","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"e2de9656_71f9d2ff","line":90,"in_reply_to":"92deb6fb_9b53f532","updated":"2026-10-05 16:27:45.000000000","message":"\u003e so i dont realy think a new api is viable unless all live migration can use it uncodtionally form day 1\n\nI\u0027m not sure where the wires are being crossed here, but I\u0027m 100% expecting all the cases to be covered from day 1, mostly because the bulk of the existing plumbing is being re-used. It\u0027s really the ordering and responsibility of completing the migration (success or failure) that changes the behavior.\n\n\u003e although i woudl actully  prefer 2.38 to pick up 2.34 if we went that rout.\n\u003e https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#maximum-in-newton\n\u003e https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id31\n\nI specifically say that we\u0027ll base this operation on 2.34\u0027s behavior below.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"dd81dc9d237be5e1b953ef9be49548bb30476f54","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"6d609fb1_bf042118","line":90,"in_reply_to":"9983572c_9d57980e","updated":"2026-10-14 12:15:08.000000000","message":"\"Old School\" lol :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06c07215266e4e68e1b5d1532f6dd4f192b50c1c","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"71324806_d709ada9","line":90,"in_reply_to":"c0865b48_bd8dfe3d","updated":"2026-10-05 15:41:32.000000000","message":"Well, the reason I don\u0027t want to do that is because I can foresee a situation where we need to continue to change the old one until the new one has proven itself to be a complete replacement. We can, of course, continue to augment the old one even though we have called it deprecated, but it\u0027s uglier.\n\nI definitely don\u0027t like the new API (and the v2 naming) but I think it\u0027s the pragmatic approach. Getting the old live migration plumbing because you chose the older microversion is extremely unpleasant, IMHO, and not \"forking\" makes eventual dropping of that API harder I think.\n\nAre you okay with a stake in the ground (i.e. a reno or similar) that we \"intend to deprecate the old migration API soon\" and leave ourselves some room to do that? Live migration is extremely critical plumbing, very hard to fully test in all real-world situations. I don\u0027t want to let purity/perfection box us into a difficult corner here.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ea259509_3f32cabc","line":90,"in_reply_to":"c1429220_7aa9b50e","updated":"2026-10-01 17:23:49.000000000","message":"I think I have a slight preference to add an entirely new API vs representing it in a new microversion of the existing one. I wouldn\u0027t want to name it V2 though, as has been expressed in earlier comments. Maybe just something different, like os-live-migrate or something normal like that.\n\nPersonally, I don\u0027t think it\u0027s important for end users to know the difference and actively choose one over the other -- and I say that to explain why I don\u0027t think we need to model the name exactly after the existing API name. The old API will be deprecated/discouraged from use but still available if there are bugs/issues in the new API.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"14beeae5_e26b4484","line":90,"in_reply_to":"e2de9656_71f9d2ff","updated":"2026-10-08 13:03:22.000000000","message":"\u003e migrateToURI3\n\nhands down the best signal this is complex enough that we should allow us to iterate the API.\n\nMy naming proposal is: \"os-live-migrate-the-ultimate-version-2\" (A nod towards Banks\u0027 \"Ultimate Ship the Second\") [and obviously I\u0027m joking here]\n\nMaybe os-cell-aware-live-migrate :)\n\n...\n\nI guess we will go with v2 :)\n\n\u003e I also think that we could consider dropping the old one eventually without the microversion lift\n\nor we can try to redirect v1 calls to v2 impl if possible in the nova-api code.\n\n\u003e Live migration is extremely critical plumbing, very hard to fully test in all real-world situations. I don\u0027t want to let purity/perfection box us into a difficult corner here.\n\n +100\nLets allow us to create something in an iterative way while keeping the critical operation working at least as good as today. Also I\u0027m pretty sure we will need more than one cycle to stabilize the new \"ultimate\" API (sorry) so freezing the legacy one is not a good tactical move in my eyes.\n\n\u003e so i dont realy think a new api is viable unless all live migration can use it uncodtionally form day 1\n\nI disagree. If I have a cloud that does not use vtpm and gpu but I want to move across cells then the new api that does not support those VM features but support cross cell live migration still be useful for me. Sure lest aim for compatibility with all those VM features. But a missing piece should not prevent us to release something to the world and \n* i) give a chance for some folks to try it and gave us feedback \n* ii) give us time to iterate not in a long ass patch series, but in actual codebase, with regular, frequent CI, and the ability to keep our sanity by only keep those parts of the problem in our brains that are open for iteration and not the whole bag.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"23b89f58a657b9c51a93e7b579dea1ce9760c31e","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"649e3d69_8b5530cf","line":90,"in_reply_to":"ea259509_3f32cabc","updated":"2026-10-01 17:57:50.000000000","message":"It seems to me like users _do_ need some way to know why we have both and which they should use (new or v2 implies this one, if no reason to use the other. I don\u0027t like \"v2\" APIs, but they\u0027re fairly prevalent across openstack. Even the libvirt API we use to do this operation is `migrateToURI3\". This isn\u0027t really a \"different way to do the same thing\" it\u0027s \"the preferred going forward\" and that implies some differentiating reason to me.\n\nI also think that we could consider dropping the old one eventually without the microversion lift in the same way we have done so with other APIs like proxies to neutron, nova-network, etc. The API can stay there but always return 403 (which has always been a possibiliy) or 409 \"None of the computes support this anymore, sorry\". It\u0027s a bit of a hack for sure, but we\u0027ve got precedent.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"41c79b35d1290e89698c4036fda6583bb53612e5","unresolved":true,"context_lines":[{"line_number":87,"context_line":"   know the differences"},{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"21dcf4f9_b3926621","line":90,"in_reply_to":"efa3ec31_a1dff774","updated":"2026-10-21 13:12:43.000000000","message":"for what its worht we did previously agree to stop adding the os- prefix to any new api enpoint, this is a new action but i think we shoudl apply that here as well.\n\nsimialrly to how we agreed to stop adding OS-EXT-SRV-ATTR: to repsocnes. when adding new field since we nolonger have extentions.\n\nso ya i would proably call it `liveMigrate` or `LiveMigrate`","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b212e23a_869dac57","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"updated":"2026-10-05 14:23:55.000000000","message":"femtonit: microversion (we all know we continue to stick with /v2 forever)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"32a936e0f7f2331d8b48b6f3760d6ac5d03367ec","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"23690324_11577049","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"00649766_7fa0319e","updated":"2026-10-29 11:30:10.000000000","message":"Stephen said:\n\u003e Do we really believe ops folks won\u0027t just stick \"always use old live migrate action\" or \"always use old live migrate microversion\" into their runbooks after a hitting enough issues?\n\nSome will for sure. But what is more likely?\n* a) ops folks hit a roadblock with v2. Switch the config back to v1 to get out of jail. Then switch the config back to v2 to continue using the new impl\n* b) ops folks hit a roadblock with v2. Call v1 to get out of jail. Sometimes will use v2 and sometimes will use v1.\n\nThe cost of reconfiguration is high enough (in both direction, but not justified in the v1 -\u003e v2 direction) that I believe a) will not really happen, while b) might. \n\nStephen said:\n\u003e can we revisit switching to the new flow in a new microversion?\n\nSo do you mean like:\n```\nif microversion \u003e\u003d 2.105:\n  new_impl()\nelse:\n  old_impl()\n```\n\nTo be honest this is the closest things to my requirements as a possible compromise if the separate action is not accepted by the nova-core team (I still think the separate action is cleaner in the long run). \n\nThe microversion has on the positive side:\n1. it is switchable runtime, no reconf needed\n2. it is explicit (compared to a hidden HTTP header)\n3. it has known implementation cost to add (compared to having a full v3 API endpoint)\n\nOn the negative side:\n1. it freezes the API of the old implementation. No new fields can be added to  feed the old implementation with data, like the AZ stuff. Which means it forces us to bet the future of the live migration action to the new implementation right now (not after it is stabilized). This is risky. If the new implementation needs 2-3 cycle to stabilize based on feedback from the field then we cannot provide the AZ feature to the field for 2-3 cycle on the old impl as stop gap.\n\n2. After the new impl is stabilized we want to rip out the old implementation (there will be shared parts not ripped out of course). This will mean nuking the live migration action on microversion \u003c 2.105 with a HTTP 410. I think that will be controversial / confusing more than, returning HTTP 410 on os-live-migrate action regardless of microversion and keep live-migrate action supported. Sure one can say we will bump the minimum microversion to 2.105 to rip out the old impl. But \n  * i) it means all other old behavior is removed for other API resources / actions in \u003c 2.105, the ops won\u0027t like that. \n  * ii) Also we never did minimum microversion bump, we basically don\u0027t know how to do it or what is the cost of it. Doing first time and moving right up to 2.105 seem very unfeasible, risky, and unlikely to happen. (This would be a totally different point if we have done min bumps in the past couple of times)\n  \n\nStephen said (emphesizis mine):\n\n\u003e So we\u0027re saying our test coverage is so large and complicated that we can\u0027t modify it to reflect changes to the implementation? **That doesn\u0027t fill me with confidence around our ability to test the new thing.** I assume those tests are there for a reason (otherwise why not delete them?): are you planning to duplicate every one of them (where still applicable) to ensure we maintain the same coverage? Also, how can we ever strip out the old code if we can\u0027t even reason about what it\u0027s testing currently?\n\nExactly! I don\u0027t believe that (writing it at least the 4th time) that we can test the new impl to be as good as the old impl just by doing functional tests while the patches sitting in gerrit. The complicated cases we have tests for are discovered while the old impl was used out there on the field. So I expect the same for the new impl as well. There will be cases from the old impl that is applicable to the new and we will test those, there will be new cases we know already and we will test those, and there will be cases unique to the new that will be discovered on the field. This is why I would like to:\n* put it out there as soon as possible even if it is not \"production ready\" yet.\n* keep a way to fall back to the old impl that is battle tested.\n\nI trust Dan that he really tried to make the old cases work and get a warm fuzzy feeling about the coverage they provide. And then he got scared that there was no warm feelings but dread instead. I have to say that https://review.opendev.org/c/openstack/nova/+/1012754 to me signals that you only got the surface of the problem at hand. The problem is not about keep running the old tests on the old impl, but \n  * i) to run the old tests on the new impl as well. (note that old tests are hooking into the live migration implementation on the compute side a lot to simulate the negative cases)\n  * ii) to feel that running the old tests on the new impl is enough to bet the future of the live migration action on that coverage (and whatever new coverage we come up with)\n  \n\nStephen said:\n  \n\u003e This is for cross-cell live migration, right? Are there changes need for same-cell migrations, or will this only bite users the first time they attempt a cross-cell migration? What\u0027s our mechanism to prevent users getting bitten with new thing?\n\nThe new impl is proposed to be used for every live migration, regardless of cross cell or same call destinaton host. This allows us to rebuild the live migration logic that gained so much complexity over the years while we learned how to do it right based on feedback from the field, changes in libvirt/qemu, etc. I look at it as a summation of all those learning and a restructured solution based on that. This is a risky business. But I think we reached the point in the complexity of the current live migration logic (especially the error handling part) and the complexity of the new feature at hand that it make sense to do such  rebuilding.\n\n---\nSummary as I run out of steam going comment by comment. \n\nThe whole cross cell live migration feature is a risky business due to both the complexity of the existing code, the complexity of the new behavior, importance of the live migration action\u0027s reliability for ops, and the timeline we have to make the new feature happen. \n\n(We are asked firmly to support it and support it very soon. There is a business decision behind it I cannot change. I know we tend to ignore this in upstream discussions but I guess desperate times...) \n\nWith this risk in mind. My goal is to contain the blast radius. Containment building tend to be ugly and costly but serves good purpose. The new API action is my containment building. \n\nI understand that the proposed separate action has a cost on the client libs. It pushes cruft there to be cleaned up later. I think we need to eat that cost. I assume the client code is simpler than our old and new live migration implementation. So I feel like it should be an acceptable compromise to carry that less complex code forward.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"6978072a788ca5c1be1479a858e101eba039703d","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2b237065_e752b1ee","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"175f1b18_45f35f84","updated":"2026-10-09 11:19:30.000000000","message":"\u003e What would be in the set \"feature that requires modern live migrate\"? Even if they don\u0027t want to target an AZ, or don\u0027t even provide a host, or don\u0027t need to cross cells, I want them using the new plumbing unless they need the old one (basically because of a bug).\n\nThe things you don\u0027t want to support in the new plumbing and would be removing in a new microversion:\n\n- `block_migration` set to `False`\n- `disk_over_commit` set to `True` (mv \u003c 2.25)\n- `force` set to `True` (mv \u003e\u003d 2.30,\u003c2.67\n\ntbc, I\u0027d also be fine with effectively ignoring those or treating them as HTTP 400 Bad Requests (since they\u0027re anti-patterns, which is why we removed them in the first place) and *always* using the new behavior regardless of microversion, but that might be a more complicated proposal?\n\n\u003e They\u0027d already opt into the older plumbing if they need one of the legacy features that live migration v1 used to support by choosing that microversion, so I\u0027m not sure the feature conditionals really make sense.\n\nThis is my point: API version doesn\u0027t have to tie into RPC version. There\u0027s no reason we can\u0027t do $newThing for an old API version. API microversions say what HTTP requests and responses look like but they don\u0027t say anything about how things are actually implemented under the hood. I\u0027m saying if a user requests a bog-standard live migration with no knobs and any microversion (be that 2.1, 2.104, or a new 2.105 (?)), use the new thing. The net result should ultimately be the same after all (instances gets moved to a new host) and how it works is an implementation detail?\n\n\u003e I also think that operators are not going to globally choose \"new or old\" nor would I want them to have to change config on their whole control plane to switch. Non-cell-migration people would just set it to legacy mode until forced to switch.\n\n`s/set it to legacy mode/continue to use the old REST API/`. See what I\u0027m getting at? I understand that we may want a way for users to opt into the old behavior, but I don\u0027t know understand why this needs to be exposed at the REST API level. It\u0027s not like they\u0027re going to use the old path for some migrations and new path for others.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"82eb634e2e1c7f716e43421159c70a3cb1895e0a","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f98004bd_e540e592","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"23690324_11577049","updated":"2026-10-29 19:48:57.000000000","message":"I am not sure any additional point to add to what gibi summarized. \n\nOne key point is that, by not doing it in the existing API with microversion, we do not need to maintain both implementations. I am sure we cannot just bump the minimum microversion to 2.105 and say the old implementation can be removed now.\n\nGiven the complexity, it is hard to maintain two implementations of live migration and improve (sometimes duplicate) both in parallel. Having a new API action gives us a way to solve this if, at some point, we can deprecate/remove the old API action.\n\nI see here we need to make a choice between the risk of breaking existing live migration vs. temporary pain for clients to handle two API actions. And I prefer to go with the latter option.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"7f50c42c229cfd88283e9b350fe729d7d7f66174","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4cd1a4bf_836096b0","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"2b237065_e752b1ee","updated":"2026-10-09 11:21:36.000000000","message":"PS: I\u0027m out on personal leave next Wednesday through Friday (at a minimum) so will miss the PTG discussion on this, but I\u0027m available to discuss on IRC before then if it would help avoid the back-and-forth. I may very well be missing something here.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e061f3e0fc95a07b307af5c1a6901af04094dc19","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fe029638_1e5bedf9","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"2b2603d9_fede40cb","updated":"2026-10-08 15:18:39.000000000","message":"\u003e \u003e so just on 1, osc negociates the latest micorverion for nova if you dont sett anything now\n\u003e \n\u003e Not quite. It\u0027s the library that does negotiation for you. This was novaclient in the past and is now SDK. SDK uses the confusingly named `Resource._min_version` attribute to determine what microversion to use for all operations on a given resource. This is an action on the `Server` resource, so currently that would be [2.100](https://github.com/openstack/openstacksdk/blob/1c3595a8df9fd512f983a411bcf6c0fda3e9bf53/openstack/compute/v2/server.py#L98). Bumping this would be sufficient to ensure OSC starts using `$newVersion`, whatever that may be.\n\u003e \n\u003e On the other point, it\u0027s still not entirely clear to me why we need a new API microversion here? The proposed new API \"feels\" almost identical to the old one (by design, fwict). Yes, the internal RPC APIs have changed dramatically, but this is irrelevant to me as an API user. Is there a reason we can\u0027t manage the switch between the correct RPC API internally, with a config opt to determine what the \"default\" mechanism is. The config opt would initially use \"$old\" by default but could migrate to \"$new\" given sufficient testing (similar to what we\u0027re doing currently for the eventlet -\u003e threading migration).\n\nWe could just handle this internally as you describe. It\u0027s the same as \"make this called from the existing action but only starting with 2.next\" except for the cost of one microversion (and some transparency, IMHO). So all the reasons I want this to be a separate thing apply to this suggestion as well: a separate action avoids disturbing the existing op, or boxing us into not being able to maintain it in parallel until we\u0027re ready to drop. When we are, we can drop the bug-for-bug compatibility cruft in v1 with `HTTP 410 Gone`.\n\nIf we were going with the plan of not having a separate op, I think my main complaint about doing what you\u0027re saying (despite it being easier) is that I think users shouldn\u0027t be using microversions to work around internal plumbing changes that wouldn\u0027t be declared behaviors in in the version history. They already have to do this for things I think we all hate, like opting into old broken live migration behavior that we have changed multiple times. Choosing which behavior they like makes the support stack complicated, and most of them are things we couldn\u0027t/wouldn\u0027t support with the v2 internals either.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7783fcf84c7d63ddca0f1cc85cbcce0698f8c92b","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"563cd281_0c04b4e1","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"2d111668_17758df4","updated":"2026-10-28 13:20:59.000000000","message":"\u003e i dont think that is a good ux or the correct way to evolve our api.\n\u003e i woudl much rather use a policy rule or cofnig option then add a new api action\n\nBoth requires nova reconfiguration that is not really good move during an escalation when the admin want to drain a compute. Also having it in the config (policy, or oslo) will basically pushes the admins to switch all further migration calls to the old impl globally for the first sign of trouble. But we want our customers to use the new impl to find the bugs.\n\n\u003e if we really want this to be its own api as i said in the ptg the correct way to do that is to start the v3/v4 api endpoint\n\u003e we can proprly mark that as experimental in keystone and we can work on that in parallel.\n\u003e exisitng client will default to v2 if we have annotheate it as experimental but operators acan opt into v3.\n\nWhy this is more correct than having a new action? I guess having a v3 and later on deprecating the whole v2 is a very big amount of work and churn for the API users. So could you reason about why we should go this way?\n\n\u003e also if its not stable enough for production i dont think we shoudl eb merging it. with my downstream hat on i certenly woudl nto be comfortable allowing a custoemr to use it, and with my upstream hat on if we have this in our api and we dont put it under an expermitnal v3 endpoint i would not consider any distibuion tha did nto supprot it to be complient under the interoperablity requirement we have for the api.\n\nI think I argued this already above. This is the point where I lost energy to repeat myself. In my eyes it cannot be production ready before it is hit production first.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f58eb61319697b2ef6aefa8bea0f633323d8e8e1","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d2fb36a6_bf5c4d4b","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"4cd1a4bf_836096b0","updated":"2026-10-09 14:02:51.000000000","message":"\u003e s/set it to legacy mode/continue to use the old REST API/. See what I\u0027m getting at?\n\nNo, I must be missing something. It seems to me like you\u0027re saying that we make the internal behavioral switch a config knob that will affect a whole deployment one way or the other. I do not think that will result in most people trying the new way and falling back in *specific* scenarios where they need to.\n\n\u003e I understand that we may want a way for users to opt into the old behavior, but I don\u0027t know understand why this needs to be exposed at the REST API level. It\u0027s not like they\u0027re going to use the old path for some migrations and new path for others.\n\nActually, that\u0027s _exactly_ what I expect and think we need to preserve. I think this needs to be a thing they use for all their migrations going forward. BUT, if they hit a snag, like find out that some combination of NUMA, vTPM and the phase of the moon haven\u0027t been properly covered and the new op is not working, I expect they will immediately use the old op and file a bug. \"This obscure combination of things doesn\u0027t work with live migration\" is the story of its life.\n\nThis really is not about structural change from the API (i.e. new parameters). Doing an unopinionated (i.e. not host- or AZ-directed) migration will be basically the same (structure) for the latest microversion of v1 and v2 in that no parameters will be provided. So we can\u0027t key off of that and we\u0027re not trying to say \"only use the new op if you need to direct to an AZ\" or anything like that. I know from a pure API perspective this feels like something that provides the same behavior as another thing so it should be the same, but in real practical terms, it\u0027s kicking off a whole different set of stuff which may or may not (initially) behave as we expect.\n\nI think it might make sense to think about this more like a stdlib evolution of a thing. We have a library function, the outcome is X, and takes no parameters. That thing has problems in how it is implemented, with some side effects, or behaviors that are hard to ensure consistency across weirdo platforms and lots of people have designed code to work with those quirks. So, the maintainers create a new method with seemingly the same external semantics, a similar name, same high-level outcome X, some different but predictable side effects and stable behavior across platforms. They drop that into stdlib, warn users the old thing will go away eventually, later deprecate it, and eventually stop supporting it. It\u0027s still one library function, with no parameters, and the plumbing inside shouldn\u0027t matter but totally does because $software. It\u0027s disturbing to people using it to have to switch, but there\u0027s a reason for it, so they can have time to make sure their stuff works with the new thing and get everything converted over. The maintainers *could* (and may in some circumstances) hook up the old symbol to the new implementation, but things that expected those quirks of the old implementation won\u0027t behave the same and sometimes the clear signal of \"that old thing isn\u0027t available anymore\" is worth the pain.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"be161da1d8de2fae5a9045b5cc8edb33f1fe4fc1","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"78f82e3a_6fb92b01","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"563cd281_0c04b4e1","updated":"2026-10-28 14:22:17.000000000","message":"Taking @gibizer@gmail.com\u0027s two comments in reverse.\n\n\u003e Also having it in the config (policy, or oslo) will basically pushes the admins to switch all further migration calls to the old impl globally for the first sign of trouble.\n\nNot a huge point, but isn\u0027t this exact thing possible/likely with the new API action, or any flow that preserves both old and new code paths and allows the user to select? Do we really believe ops folks won\u0027t just stick \"always use old live migrate action\" or \"always use old live migrate microversion\" into their runbooks after a hitting enough issues?\n\n\u003e Both requires nova reconfiguration that is not really good move during an escalation when the admin want to drain a compute.\n\nThis is fair. While I do thing having a global config option is a necessary piece to providing an off-ramp for the old code path, we don\u0027t want to force people to change their config at the most stressful times. This being the case, can we revisit switching to the new flow in a new microversion? Dan said:\n\n\u003e 1. OSC by default will continue driving people to the old one by default\n\u003e 2. If we need to make small changes or fixes to the existing API, we\u0027ll be stuck with kinda having closed the door forever on that\n\u003e 3. We have to disturb the existing massive set of functional tests (to some degree) that provide almost all of our current coverage on the v1 API. So many of those involve the cleanup procedures that it will at least double the effort here going that route.\n\nI\u0027d taken this at face value without much thought, but I don\u0027t think any of these are good reasons to not use microversions to handle this. (1) isn\u0027t true, as I\u0027ve noted above. (2) is true but seems a moot point given `os-liveMigrate` hasn\u0027t changed since [2.68](https://docs.openstack.org/api-ref/compute/#live-migrate-server-os-migratelive-action) ([Stein](https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id62), [April 2019](https://releases.openstack.org/)) and all our future effort is going to be focused on the new path. (3) is a mechanical issue and the kind of thing an LLM is exceedingly good at.\n\nBy comparison, the arguments *for* doing this are numerous:\n\n1. We already need a new microversion to handle the new `availability_zone` parameter\n2. OSC, SDK, Gophercloud etc. get the new behavior for free, without having to concoct weird ways to switch between actions (since we can\u0027t depend on microversion checks like we would normally do so). Applications don\u0027t have to be rewritten.\n3. Admins continue to have their escape hatch (an older microversion) for some time (note: I do still think an option to allow the `os-liveMigrate` action to *always* use the new code path, as part of the eventual off-ramp for the old code path, but I\u0027ll admit this would be a fairly trivial follow-up)\n4. We don\u0027t have to carry the old, now duplicate code path and old actions in clients/SDKs ✨forever✨\n\nWhat am I missing?\n\nPS: I\u0027ll reiterate that I\u0027m happy to discuss this on IRC or somewhere higher bandwidth if it would help? Just let me know.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"edc59686f8f5bfcf4da66489d3d16ac699a7ffa1","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f51530c2_c0385171","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"56bf549d_a818209a","updated":"2026-10-05 16:27:45.000000000","message":"The desire to make this a different operation is largely because:\n\n1. I don\u0027t want to disturb the existing migration function\n2. I don\u0027t want to disturb the existing huge set of tests we have for it\n3. I don\u0027t want this work to completely eliminate the possibility to continue supporting v1 migration if and while we build trust in the new flow\n\nThere\u0027s absolutely nothing preventing us from wiring up 2.next to driving the new flow if that\u0027s what people want. It just means that:\n\n1. OSC by default will continue driving people to the old one by default\n2. If we need to make small changes or fixes to the existing API, we\u0027ll be stuck with kinda having closed the door forever on that\n3. We _have_ to disturb the existing massive set of functional tests (to some degree) that provide almost all of our current coverage on the v1 API. So many of those involve the cleanup procedures that it will at least double the effort here going that route.\n\nFor #3, I\u0027ve basically been going through each functional test we have for v1, deciding if it even applies to v2, and if so, adding a new functional test for the new API that recreates the same scenario. That becomes a lot harder if they\u0027re unified (I know because I spent a ton of time in my first PoC trying to make existing tests work).","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"101a9c34b304a891f64e817c03dcefe709e7dfad","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a52f0170_ed29317a","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"5d73547e_904f10d7","updated":"2026-10-13 10:24:58.000000000","message":"\u003e \"maybe we\u0027ll need time to get this right\"\n\nI\u0027m on the side of being pragmatic here. Getting it right will not happen while we iterating on it locally or in gerrit. It happens when we ship it to real customers and they start doing weird things with it. So I consider this new implementation of live migration as something that is not stable until some of our big customers are run with it for a while and reported at least 10+ facepalm bugs for us about it.\n\nWe also know from the support cases we work on that these customers can be pretty insistent to get out of trouble. Hence why having the old v1 \"untouched\" gives us a nice out of jail card here. I\u0027m willing to compromise on mechanism the client asks for the old v1. What I need is \n1) have a way to call the old code if the new code falls over without any complicated reconfiguration and service restarts as this will be done during an escalation where time matters.\n\n2) have a way to maintain the old codepath while freely iterating on the new code path. So that if a facepalm bug is filed today to the old code path I\u0027m not forced to only fix it in the new path while the old is frozen into 2.104. (I know I tend to say that bugfix does not require a microvesion, but others are more insistent on that if the semantics of the call changes then it is a new microversion)\n\n\u003e Okay, so this alternate path is the \"get me out of my immediate hole\" path? I\u0027m still not that should be necessary (we\u0027ve changed plenty under the hood over the years and never done an API-visible thing like this for it)\n\nBtw, the cross cell resize is behind a by default nobody API policy. So we do have priory art saying: I don\u0027t trust the new semantics of this API call so I would like to have a flag to move back to the old semantics **on all new microversion**. We just had even less confident in that case and never changed the default of the policy to allow cross cell resize for admins by default.\n\nWe logically want something similar here. We want to keep the old semantics for all new microversions (until we can drop the old semantics). While we iterating on a new semantics publicly in the shipped product. We just want to make it more consumable than the cross cell resize as we have sizeable customer needs behind it. So we want something that is publicly available by default (for admins) while we want a super easy way (not even a policy change and api restart) to fall back to the old semantics.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"56a457080d3734bfb47b1b972c74d2fea0d13c88","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"00649766_7fa0319e","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"5df2a524_06bb393a","updated":"2026-10-28 18:25:01.000000000","message":"\u003e\u003e For (3), as I mentioned I spent weeks (with an LLM of course, else it would have taken me months) trying to get it to separate the behaviors. It is definitely possible, but the number of changes made to the tests made me immediately no longer trust their ability to confirm the old behavior. And that was well before I even finished.\n\u003e \n\u003e So we\u0027re saying our test coverage is so large and complicated that we can\u0027t modify it to reflect changes to the implementation? That doesn\u0027t fill me with confidence around our ability to test the new thing. I assume those tests are there for a reason (otherwise why not delete them?): are you planning to duplicate every one of them (where still applicable) to ensure we maintain the same coverage? Also, how can we ever strip out the old code if we can\u0027t even reason about what it\u0027s testing currently?\n\nAlso pushed https://review.opendev.org/c/openstack/nova/+/1012754/. This only touches part of the testing gap - you\u0027ve specifically called out that we want to reuse code where possible - but it\u0027s a start that isolates the most complex \"live migration\". It\u0027s as much as I can do currently without 👇 and talking in the abstract.\n\n\u003e Could you push the WIP test changes somewhere so we could take a look at it? I find this really surprising.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"a70af13e46116dee99e88f8c37de290b0765e545","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5d73547e_904f10d7","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"7247f577_f12c45dd","updated":"2026-10-09 22:53:19.000000000","message":"\u003e \u003e \u003e Actually, that\u0027s exactly what I expect and think we need to preserve.\n\u003e \u003e \n\u003e \u003e Wait, really? Why would operators do this rather than rolling a bugfix for the issue?\n\u003e \n\u003e I think maybe you misunderstood what I meant by \"immediately\". I said \"immediately use the old op and file a bug\". Meaning, they would do the migration with the old op in the subsequent _minutes_ after hitting an issue and file a bug. Of course when there is a bug fix to roll out, they\u0027d do so and expect it to be fixed. That won\u0027t happen in minutes. Every support case I\u0027ve been involved in where live migration is breaking (which happens plenty often) they\u0027re always in an immediate hurry and even a hotfix (which is often not possible) would be too long to wait. It\u0027s almost always involves taking downtime to get out of the jam by shelving or resorting to cold migration and it\u0027s never a happy conversation. Being able to hit the old operation until a fix is available is all I\u0027m talking about, and I think it\u0027s the \"don\u0027t want to disturb the existing path\" sentiment several other people here have expressed.\n\nOkay, so this alternate path is the \"get me out of my immediate hole\" path? I\u0027m still not that should be necessary (we\u0027ve changed plenty under the hood over the years and never done an API-visible thing like this for it) but if you\u0027re sure we do...can we just implement this as a minimal documented side channel like a HTTP header? At least that\u0027s something a client like OSC could drop in a cycle or four, while others like gophercloud could ignore entirely.\n\nbtw, I would really like to examine whether this legacy path is needed. It seems to be being assumed here and I\u0027m fairly uncomfortable with the idea that we\u0027re thinking of merging something that we expect to be broken for enough users that we can justify a whole new API...\n\n\u003e \u003e Maintaining an internal list of \"things that work with new flow\" vs \"things that work with old\" seems like far more hassle than just opting out of the new flow entirely or fixing the bug (and hopefully) pushing it upstream), no? \n\u003e \n\u003e Of course that\u0027s not what I\u0027m suggesting. We can and should expect everything that works with the old flow to work with the new flow. The reality is that proving that out 100% and trusting it is something that happens with soak time.\n\nBut APIs, like puppies, are not just for ~Christmas~ the duration of the soak time, they are ✨forever✨ 😅 This is a huge lift for a \"maybe we\u0027ll need time to get this right\" kind of thing.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6dccce643685318bc216f2ed680eae64eeeb8b6d","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7247f577_f12c45dd","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"72e1c086_1398112f","updated":"2026-10-09 21:21:07.000000000","message":"\u003e \u003e Actually, that\u0027s exactly what I expect and think we need to preserve.\n\u003e \n\u003e Wait, really? Why would operators do this rather than rolling a bugfix for the issue?\n\nI think maybe you misunderstood what I meant by \"immediately\". I said \"immediately use the old op and file a bug\". Meaning, they would do the migration with the old op in the subsequent _minutes_ after hitting an issue and file a bug. Of course when there is a bug fix to roll out, they\u0027d do so and expect it to be fixed. That won\u0027t happen in minutes. Every support case I\u0027ve been involved in where live migration is breaking (which happens plenty often) they\u0027re always in an immediate hurry and even a hotfix (which is often not possible) would be too long to wait. It\u0027s almost always involves taking downtime to get out of the jam by shelving or resorting to cold migration and it\u0027s never a happy conversation. Being able to hit the old operation until a fix is available is all I\u0027m talking about, and I think it\u0027s the \"don\u0027t want to disturb the existing path\" sentiment several other people here have expressed.\n\n\u003e Maintaining an internal list of \"things that work with new flow\" vs \"things that work with old\" seems like far more hassle than just opting out of the new flow entirely or fixing the bug (and hopefully) pushing it upstream), no? \n\nOf course that\u0027s not what I\u0027m suggesting. We can and should expect everything that works with the old flow to work with the new flow. The reality is that proving that out 100% and trusting it is something that happens with soak time.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"460860054bd36b225ab544a8fd2eb235da351c16","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f62e00e9_a063449d","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"78f82e3a_6fb92b01","updated":"2026-10-28 14:46:53.000000000","message":"The flow chart here:\n\nhttps://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-need-a-new-microversion\n\nSpecifically leads us to \"no microversion needed\" for something that is purely plumbing on the back end. Extract the AZ parameter from this since sean already wants that the be separate and it is unrelated to \"are we doing the old thing or the new thing\". Without that, running the new plumbing versus the old one would be a microversion with no meaning other than \"do the new thing, you know what it is\". With it, it becomes more confusing because the operator is likely to see \"oh I need AZ targeting so I use 2.105 but ... whoa, this is different\".\n\nPlease don\u0027t say (2) above is a moot point because it is a major reason for _not_ re-using the same action to me. I don\u0027t want to make the new plumbing have to be capable of doing some of the insane things the old one was that we never want to support, like force/host. If we stick with the same action and pretend like nothing fundamental has changed, then we have to keep that functionality.\n\nFor (3), as I mentioned I spent weeks (with an LLM of course, else it would have taken me months) trying to get it to separate the behaviors. It is definitely possible, but the number of changes made to the tests made me immediately no longer trust their ability to confirm the old behavior. And that was well before I even finished.\n\nThe new mechanism has additional requirements on the compute nodes that are not easy for us to inspect from the API. For example, they have to have configured their source and destination nodes for a compatible instance name template. That\u0027s not something we can tell at a distance, and has nothing to do with the RPC versions available in the deployment. It\u0027s easy for us to say \"this new admin-only operation requires admin-only changes to your deployment before you can expect it to work.\" Normally for any such change via microversion, we\u0027d clamp to an RPC, service version, etc (which prevents use until everything is upgraded) but we literally can\u0027t do that here. However, it\u0027s something admins can easily grok, control after they\u0027ve made the change by enabling the policy, etc.\n\nI think (4) is sort of the domain of the client, but I also think that comparing the relative debt of a function is minor to the weight of the decades-old implementation we want to rip out on the server side. Surely the client can just proxy the `410 Gone` through to the caller just like for the serial consoles action we removed, right? If you want the client to try to call the new operation if only accepted parameters are passed and the microversion is not capped, then that\u0027s fine too. But saying we should keep force/host forever because of the client seems hard to justify to me.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"cc74b135551534f0920ed631c2b2751e579f3ac2","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2b2603d9_fede40cb","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"87e52289_acb27eb3","updated":"2026-10-08 14:18:06.000000000","message":"\u003e so just on 1, osc negociates the latest micorverion for nova if you dont sett anything now\n\nNot quite. It\u0027s the library that does negotiation for you. This was novaclient in the past and is now SDK. SDK uses the confusingly named `Resource._min_version` attribute to determine what microversion to use for all operations on a given resource. This is an action on the `Server` resource, so currently that would be [2.100](https://github.com/openstack/openstacksdk/blob/1c3595a8df9fd512f983a411bcf6c0fda3e9bf53/openstack/compute/v2/server.py#L98). Bumping this would be sufficient to ensure OSC starts using `$newVersion`, whatever that may be.\n\nOn the other point, it\u0027s still not entirely clear to me why we need a new API microversion here? The proposed new API \"feels\" almost identical to the old one (by design, fwict). Yes, the internal RPC APIs have changed dramatically, but this is irrelevant to me as an API user. Is there a reason we can\u0027t manage the switch between the correct RPC API internally, with a config opt to determine what the \"default\" mechanism is. The config opt would initially use \"$old\" by default but could migrate to \"$new\" given sufficient testing (similar to what we\u0027re doing currently for the eventlet -\u003e threading migration).\n\nPS: I\u0027ve only skimmed everything after this section. I assume others have the main RPC implications of this in hand.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"212aff88b57fd4929827036de3b58242f613f956","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"175f1b18_45f35f84","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"9a461c5a_6603a81b","updated":"2026-10-08 18:17:31.000000000","message":"What would be in the set \"feature that requires modern live migrate\"? Even if they don\u0027t want to target an AZ, or don\u0027t even provide a host, or don\u0027t need to cross cells, I want them using the new plumbing unless they need the old one (basically because of a bug).\n\nThey\u0027d already opt into the older plumbing if they need one of the legacy features that live migration v1 used to support by choosing that microversion, so I\u0027m not sure the feature conditionals really make sense. I also think that operators are not going to globally choose \"new or old\" nor would I want them to have to change config on their whole control plane to switch. Non-cell-migration people would just set it to legacy mode until forced to switch.\n\nBut either way, going this route at all closes off the desire I have (and I think others have expressed) to not close off the potential maintenance of v1 until we\u0027re ready to actually kill it.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"41c79b35d1290e89698c4036fda6583bb53612e5","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2d111668_17758df4","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"a52f0170_ed29317a","updated":"2026-10-21 13:12:43.000000000","message":"right this is why i raised the policy roles orginally.\ni suggesting we either defautl both to admin or both to nobody\n\nthe only justification i have see for a new api action or microversion is that they may be bugs and we do not trust the qualtiy of the code we will write so we will expsoe and internal impleiaon detail (old or new workflow)  to our end users by way of a new api action.\n\ni dont think that is a good ux or the correct way to evolve our api.\n\ni woudl much rather use a policy rule or cofnig option then add a new api action\n\nif we really want this to be its own api as i said in the ptg the correct way to do that is to start the v3/v4 api endpoint\nwe can proprly mark that as experimental in keystone and we can work on that in parallel.\n\nexisitng client will default to v2 if we have annotheate it as experimental but operators acan opt into v3.\n\nalso if its not stable enough for production i dont think we shoudl eb merging it. with my downstream hat on i certenly woudl nto be comfortable allowing a custoemr to use it, and with my upstream hat on if we have this in our api and we dont put it under an expermitnal v3 endpoint i would not consider any distibuion tha did nto supprot it to be complient under the interoperablity requirement we have for the api.\n\ndistorbution do not get to pick and choose api microversion or endpoints within the sable api enpoint (V2)\n\nthe api sig giudliens document how version discovery and endpoitn status are expected to work.\n\nhttps://opendev.org/openstack/api-sig/src/branch/master/guidelines/discoverability.rst#versioned-version-discovery\n\nhttps://opendev.org/openstack/api-sig/src/branch/master/guidelines/discoverability.rst#endpoint-status\n\ni have not seen a jsutificaion for why we would diverge form that path.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"203a264323570d09c4f7e746bc4eda8fd03c574e","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"26d18bc6_5b016a64","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"a6cfd454_a5af1602","updated":"2026-10-30 12:04:23.000000000","message":"Tried to capture things in a follow-up:\n\nhttps://review.opendev.org/c/openstack/nova-specs/+/1013025","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"69ff7e901f24f12e6bcfbcb2c35cd6f0e3480c15","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5df2a524_06bb393a","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"a98660b9_c4d4eb88","updated":"2026-10-28 16:20:55.000000000","message":"\u003e \u003e The flow chart here:\n\u003e \u003e \n\u003e \u003e https://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-need-a-new-microversion\n\u003e \u003e \n\u003e \u003e Specifically leads us to \"no microversion needed\" for something that is purely plumbing on the back end.\n\u003e \n\u003e I agree, this is plumbing on the backend that doesn\u0027t affect the API surface, thus my suggestion to make this a config knob. But you\u0027ve said you *want* to expose this backend change via the API so we\u0027re having to ignore our own rules. If we had an equivalent \"do I need a new API\" doc then I can\u0027t imagine said doc would support adding a new API that looks identical to an existing one (save for a removed suffix)?\n\nThinking more on this, there *is* an API change: you can now request hosts that live in other cells (currently a HTTP 400) and get cross-cell live migration. That makes this similar to other \"signalling\" microversions like 2.95 (\"Evacuate will now stop instance at destination.\") or 2.93 (\"Add support for volume backed server rebuild\"). A new microversion would allow users to opt-in/discover this new functionality.\n\nThis is probably something we want to note in our docs? I\u0027ve pushed https://review.opendev.org/c/openstack/nova/+/1012733 to correct the oversight. Would appreciate a review here 🙏","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1b8d4f5d56f7cd4cd407ddb0a9a75dd630c9cc10","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"56bf549d_a818209a","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"b212e23a_869dac57","updated":"2026-10-05 16:10:33.000000000","message":"well we could change that in the future and probably should but i dont think this change is the right place to taht.\n\nif we have a v4 or v3 take too thats a much much larger change then replacing the exiting migration api endpoint with a new one.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"0e910dcdbe41db619453d49b4ad5a6213bd76a68","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"72e1c086_1398112f","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"d2fb36a6_bf5c4d4b","updated":"2026-10-09 17:27:20.000000000","message":"\u003e Actually, that\u0027s exactly what I expect and think we need to preserve.\n\nWait, really? Why would operators do this rather than rolling a bugfix for the issue? Maintaining an internal list of \"things that work with new flow\" vs \"things that work with old\" seems like far more hassle than just opting out of the new flow entirely or fixing the bug (and hopefully) pushing it upstream), no? Bringing it further, what about when the bug that caused \"some combination of NUMA, vTPM and the phase of the moon\" to not be properly covered gets fixed? Are we going to introduce a new API microversion to signal that, or does an operator maintaining multiple clouds (which won\u0027t necessarily be all on the same patch release) have to remember/guess what API to use?\n\n\u003e I think it might make sense to think about this more like a stdlib evolution of a thing.\n\nI don\u0027t think they\u0027re the same. We\u0027ve determined that the REST API looks, feels the same here and behaves (to an API user) exactly as it did before (with the sole exception of allowing cross-cell migration, but we don\u0027t expose anything to do with cells via the API). By comparison, the libvirt migration APIs (`MigrateToURI3`, `MigrateToURI2` etc.) brought up elsewhere here are wrappers around RPC calls that have changed fundamentally in their inputs and outputs.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"26c43d5e96e8a6bff74149030375596e56fb7b86","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"87e52289_acb27eb3","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"f51530c2_c0385171","updated":"2026-10-05 16:47:17.000000000","message":"so just on 1, osc negociates the latest micorverion for nova if you dont sett anything now\n\nit has for a couple of release although our i think it came in bobcat so downstream it missed that change.\n\nso if we use the exsiting api it would opt everyone into the new semantics\n\nbut just setting that asisde for the moment on the osc side even if its a new api endpoint we can just teach it to use it preferencally as addign that endpoint will need a microverion bump regardless so we have the means to push folks to the behvior we like either way.\n\nwhat i dont wnat to have to do is make the endpoitn we call configurable in watcher as something that watcher or the oeperator need to care about.\n\nso if watcher or horizon can unconditonly call the new api (modulo bugs) that mostly ok with me.\n\nwe effectivly are using 2.34 sematics already we actully pin the minversion we use in watcher to 2.56 and max to 2.96, because we were using python-novaclient\nbut we can remove that now that we moved ot the sdk, that was just the pin in ci not the code, the code does depend on and enfoce 2.56 however.\n\n2.56 is \n\n```\nUpdates the POST request body for the migrate action to include the optional host string field defaulted to null. If host is set the migrate action verifies the provided host with the nova scheduler and uses it as the destination for the migration.\n```\nwhich is basiclaly queens era nova.\n\ni have not checked horizon but i would expect it to use something contemporary or newer then that.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"121319c0b3ef9c14e06017f5e1b48f7bc2db1a27","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a98660b9_c4d4eb88","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"f62e00e9_a063449d","updated":"2026-10-28 15:26:14.000000000","message":"\u003e The flow chart here:\n\u003e \n\u003e https://docs.openstack.org/nova/latest/contributor/microversions.html#when-do-i-need-a-new-microversion\n\u003e \n\u003e Specifically leads us to \"no microversion needed\" for something that is purely plumbing on the back end.\n\nI agree, this is plumbing on the backend that doesn\u0027t affect the API surface, thus my suggestion to make this a config knob. But you\u0027ve said you *want* to expose this backend change via the API so we\u0027re having to ignore our own rules. If we had an equivalent \"do I need a new API\" doc then I can\u0027t imagine said doc would support adding a new API that looks identical to an existing one (save for a removed suffix)?\n\n\u003e Extract the AZ parameter from this since sean already wants that the be separate and it is unrelated to \"are we doing the old thing or the new thing\". Without that, running the new plumbing versus the old one would be a microversion with no meaning other than \"do the new thing, you know what it is\". With it, it becomes more confusing because the operator is likely to see \"oh I need AZ targeting so I use 2.105 but ... whoa, this is different\".\n\nRight. And the new API action is an action with no meaning other \"do the new thing, you know what it is\". Same difference, only now we\u0027ve foisted a new action on the world 😕\n\n\u003e Please don\u0027t say (2) above is a moot point because it is a major reason for _not_ re-using the same action to me. I don\u0027t want to make the new plumbing have to be capable of doing some of the insane things the old one was that we never want to support, like force/host. If we stick with the same action and pretend like nothing fundamental has changed, then we have to keep that functionality.\n\nWho said anything about supporting those old things on the API? I didn\u0027t. When it comes time to remove old code path we can remove those things too. HTTP 400 (Bad Request) ought to do the trick.\n\n\u003e For (3), as I mentioned I spent weeks (with an LLM of course, else it would have taken me months) trying to get it to separate the behaviors. It is definitely possible, but the number of changes made to the tests made me immediately no longer trust their ability to confirm the old behavior. And that was well before I even finished.\n\nSo we\u0027re saying our test coverage is so large and complicated that we can\u0027t modify it to reflect changes to the implementation? That doesn\u0027t fill me with confidence around our ability to test the new thing. I assume those tests are there for a reason (otherwise why not delete them?): are you planning to duplicate every one of them (where still applicable) to ensure we maintain the same coverage? Also, how can we ever strip out the old code if we can\u0027t even reason about what it\u0027s testing currently?\n\nCould you push the WIP test changes somewhere so we could take a look at it? I find this really surprising.\n\n\u003e The new mechanism has additional requirements on the compute nodes that are not easy for us to inspect from the API. For example, they have to have configured their source and destination nodes for a compatible instance name template. That\u0027s not something we can tell at a distance, and has nothing to do with the RPC versions available in the deployment. It\u0027s easy for us to say \"this new admin-only operation requires admin-only changes to your deployment before you can expect it to work.\" Normally for any such change via microversion, we\u0027d clamp to an RPC, service version, etc (which prevents use until everything is upgraded) but we literally can\u0027t do that here. However, it\u0027s something admins can easily grok, control after they\u0027ve made the change by enabling the policy, etc.\n\nThis is for cross-cell live migration, right? Are there changes need for same-cell migrations, or will this only bite users the first time they attempt a cross-cell migration? What\u0027s our mechanism to prevent users getting bitten with new thing?\n\n\u003e I think (4) is sort of the domain of the client, but I also think that comparing the relative debt of a function is minor to the weight of the decades-old implementation we want to rip out on the server side. Surely the client can just proxy the `410 Gone` through to the caller just like for the serial consoles action we removed, right? If you want the client to try to call the new operation if only accepted parameters are passed and the microversion is not capped, then that\u0027s fine too. But saying we should keep force/host forever because of the client seems hard to justify to me.\n\nAgain, I don\u0027t know where you picked this up from. I never said we need to keep stuff in Nova? 😅 Clients continue to support things that are no longer supported in services. For example, gophercloud, openstacksdk and OSC all continue to support identity\u0027s v2 API for compat with older clouds. We don\u0027t force keystone to continue supporting that. My point here is that we currently expose this to users via e.g. `openstack server migrate --live-migration` (OSC), `conn.compute.live_migrate_server` (SDK), `servers.LiveMigrate` (Gophercloud). All of those now need weird duplicate implementations because there are effectively two duplicate implementations in practice now. And anyone who is using these is tooling now has to rework their tooling to call new thing at some point. *That\u0027s* what I said.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"1e470f6f215a239d61d31ad61bfdf88e40226c6a","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a6cfd454_a5af1602","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"f98004bd_e540e592","updated":"2026-10-30 11:22:46.000000000","message":"I\u0027ll adopt gibi\u0027s approach to reply since this is looooong. From gibi:\n\n\u003e So do you mean like:\n\u003e \n\u003e ```\n\u003e if microversion \u003e\u003d 2.105:\n\u003e   new_impl()\n\u003e else:\n\u003e   old_impl()\n\u003e ```\n\nYes, exactly. We can eventually (many cycles from now, once we\u0027ve proven it out) simplify this to:\n\n```\nnew_impl()\n```\n\nbut that\u0027s a good way down the line.\n\nAlso from gibi:\n\n\u003e On the negative side:\n\u003e\n\u003e 1. it freezes the API of the old implementation. ...\n\u003e 2. After the new impl is stabilized we want to rip out the old implementation (there will be shared parts not ripped out of course)\n\nOur goal here is to eventually only have one implementation, so why would we be investing **any** effort into the old implementation beyond bugfixes? We\u0027ve clearly decided it\u0027s a technical dead-end. Our sole focus moving forward should be stabilising and improving the new code path.\n\nAnother one from gibi:\n\n\u003e I understand that the proposed separate action has a cost on the client libs. It pushes cruft there to be cleaned up later. I think we need to eat that cost. \n\nWe have to carry that cruft forever because we need to support old clouds. And we have not covered the migration path for the following commands/calls:\n\n- `openstack server migrate --live-migration` (OSC)\n- `conn.compute.live_migrate_server` (SDK)\n- `servers.LiveMigrate` (Gophercloud)\n- Horizon\u0027s live migration flow\n- \u003cwhatever the rust CLI/TUI/API presents\u003e\n\nWhat do these things look like in a new world? How do we expose both APIs to users without leaking implementation details to them? If we were to give this operation a different name then this wouldn\u0027t even be a discussion, but we\u0027re not: we\u0027ve two operations with the same name running alongside each other.\n\nFinally one from gmaan:\n\n\u003e One key point is that, by not doing it in the existing API with microversion, we do not need to maintain both implementations. I am sure we cannot just bump the minimum microversion to 2.105 and say the old implementation can be removed now.\n\nI\u0027ve discusesd this already but the only reason for duplicate code paths is to allow us time to harden the new one. We don\u0027t need to keep using the old code path for \u003c v2.105 forever. I\u0027ve already outlined how we can do this migration down the line.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"69cc51aa4310abcfbfaff126adf1902de25c07e5","unresolved":true,"context_lines":[{"line_number":88,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":89,"context_line":"   remove more in the long run)"},{"line_number":90,"context_line":""},{"line_number":91,"context_line":"The new API will inherit the semantics of the current latest-version"},{"line_number":92,"context_line":"``os-migrateLive`` action. Specifically:"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a461c5a_6603a81b","line":91,"range":{"start_line":91,"start_character":61,"end_line":91,"end_character":68},"in_reply_to":"fe029638_1e5bedf9","updated":"2026-10-08 17:00:44.000000000","message":"\u003e If we were going with the plan of not having a separate op, I think my main complaint about doing what you\u0027re saying (despite it being easier) is that I think users shouldn\u0027t be using microversions to work around internal plumbing changes that wouldn\u0027t be declared behaviors in in the version history.\n\nThis may not have came across (apologies if it did and I\u0027ve misunderstood you) but my thinking here is that this (a user needing to opt in to new behavior) _wouldn\u0027t_ be the case *except* if using the new fields you\u0027re adding. Rather, we\u0027d have logic like this in either the `MigrateServerController._migrate_live` REST API controller method or `API.live_migrate` method it calls:\n\n```\nif using feature that requires modern live migrate:\n    return do_modern_live_migrate()\n\nif conf.compute.prefer_legacy_live_migrate or if using feature that requires legacy live migrate\n    return do_legacy_live_migrate(...)\n\nreturn do_modern_live_migrate()\n```\n\n...with the expectation that `[compute] prefer_legacy_live_migrate` would initially default to `True` and eventually switch to `False` before being removed (like we\u0027re doing with `concurrency_backend`). An operator that has a desire to always use the new path (e.g. to support cross-cell live migration) would opt to change `[compute] prefer_legacy_live_migrate` sooner while we continue to tweak this under the hood as needed. and the other users of the `do_legacy_live_migrate` path could also be removed by either (a) bumping `min_version` or (b) just starting raise HTTP 400 (Bad Request) if someone attempts to use the thing we no longer support.\n\nIs that feasible/reasonable, or have I missed something?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"},{"line_number":95,"context_line":"   consulted to make sure the host is suitable"},{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6cc8a860_bfeddd41","line":98,"range":{"start_line":96,"start_character":0,"end_line":98,"end_character":53},"updated":"2026-10-05 14:23:55.000000000","message":"I\u0027d honestly let them die in silence 😄 \nYou said we\u0027ll fork from the latest microversion in date, I got it.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":93,"context_line":""},{"line_number":94,"context_line":" - A ``host`` parameter is accepted, and if provided, the scheduler will be"},{"line_number":95,"context_line":"   consulted to make sure the host is suitable"},{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c96eff35_a4a1866c","line":98,"range":{"start_line":96,"start_character":0,"end_line":98,"end_character":53},"in_reply_to":"6cc8a860_bfeddd41","updated":"2026-10-08 17:23:57.000000000","message":"Right, but if we imported the latest exactly, we\u0027d bring these in. What I want is the _behavior_ of the latest microversion where the defaults were assumed.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"cc74b135551534f0920ed631c2b2751e579f3ac2","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"09a9666a_bed65891","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"updated":"2026-10-08 14:18:06.000000000","message":"nit: do we need the `dest_` prefix? Isn\u0027t it implied? We don\u0027t have `dest_host`...","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e061f3e0fc95a07b307af5c1a6901af04094dc19","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7ec93979_51cabdfa","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"09a9666a_bed65891","updated":"2026-10-08 15:18:39.000000000","message":"We don\u0027t _need_ it. I put it in there because it\u0027s not updating the instance\u0027s pinned availability_zone. So sort of handwavy \"this is not a field that will be set after the operation, RESTfulness wise.\" In that respect \"host\" kinda is more idempotent (but it\u0027s not really named host either).\n\nSo yeah I don\u0027t care much really, but that was the thinking.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"212aff88b57fd4929827036de3b58242f613f956","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"78b279c2_c08ca709","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"1f2f1a38_4a2744c9","updated":"2026-10-08 18:17:31.000000000","message":"Sure, I thought I was copying a `dest_` example from somewhere else, but it\u0027s been a few weeks.\n\nI\u0027m really happy to change the name of it to anything and/or remove the prefix based on the group consensus, so I\u0027ll let the rest of the board members opine on the color of the bike shed.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7783fcf84c7d63ddca0f1cc85cbcce0698f8c92b","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"060b1ecb_03ddc52c","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"2b5411aa_2516cbc0","updated":"2026-10-28 13:20:59.000000000","message":"Can we try not to boil the ocean in this already pretty complicated new implementation work? Can we do iterative development?\n\nThis is a spec about cross cell live migration. There can be another about cross AZ live migration.\n\nI\u0027m pretty sure if this is all or nothing then we will have nothing. I don\u0027t believe that anybody\u0027s goal here is to argue until the heat death of the universe. Can we make steps forward? Can the first step be incomplete with a promise that we continue making further steps to complete it?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e7233113f02289940e8b2ba01921b1dc939522d7","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"d9f82bda_b595a00b","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"7710ff33_e5af0d06","updated":"2026-10-21 14:35:22.000000000","message":"i woudl be ok with simplfying the eye chart for unshleve if we were to make all move ops consitent.\n\nim also kind of ok with the pin not being reverted.\n\ni think that is what im going to propose on teh watcher side if we do not just delegate this to nova becasue i dont think we shoudl be guessign why the migration failed if the vm end up in error.\n\nif the vem is active on the souce node when the migraiton goes to failled we could repin but the semaitcs will be complex and it not clear this shoudl be a policy decsion left to an adimin in that case.\n\nwaht i really want is uniformity betwen the move operations so that operator do nto have to undersnad howe ver of them differs.\nim not married to the idea that it has to be exactly like unshleve but that cold migrate, live migrate, unshelve and evacuated shoudl all provide the same mechainiums to specifiy a desired destinatnon (host and/or az) adn that we have effectivly the same sematics for each opertion.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6f2885410f23dd57435224c86d4243dab9df10db","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"94424dc8_355e719e","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"78b279c2_c08ca709","updated":"2026-10-15 19:23:47.000000000","message":"Note that I\u0027m not changing this because nobody else chimed in and it matches the code as of now. I\u0027m happy to change it in the code and here if anyone else feels strongly about either of the three options presented here.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"3aafc5d50e25a66705b1adb9cd49a1d2ebfe2afb","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"1f2f1a38_4a2744c9","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"7ec93979_51cabdfa","updated":"2026-10-08 17:12:59.000000000","message":"Fair point. In that case, could I suggest `target_` as a prefix instead? Pure bikeshedding of course, but I think this captures the intent better","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"41c79b35d1290e89698c4036fda6583bb53612e5","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"b4d96759_09903b19","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"94424dc8_355e719e","updated":"2026-10-21 13:12:43.000000000","message":"i would strongly prefer using `availability_zone`\n\nin train we added `availability_zone` to unshlve\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/train/implemented/support-specifying-az-when-restore-shelved-server.html\n\nand in zed we then later added host\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/zed/implemented/unshelve-to-host.html\n\nin both spec i requested that we also do this for cold migrate and it was defered\n\nin this case im not hapy defering colde migrate again so if we are added az i expect us to implemnt  support for az and host it for cold migrate and live migrate and evacuate and support host and az in all 3 with the same filed names and behvior as unshleve and to use constitent filed names and semantics\n\nhttps://github.com/openstack/nova-specs/blob/master/specs/zed/implemented/unshelve-to-host.rst?plain\u003d1#L42-L98\n\n\n```\nCurrent behavior:\n\n+----------+------------------------+----------------------------------------+\n| Boot     | Unshelve after offload | Result                                 |\n+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\n| No AZ    | No AZ                  | Free scheduling, reqspec.AZ kept None  |\n+----------+------------------------+----------------------------------------+\n| No AZ    | AZ                     | Schedule in the AZ, update reqspec.AZ  |\n|          |                        | to the requested one                   |\n+----------+------------------------+----------------------------------------+\n| With AZ  | No AZ                  | Schedule in original AZ, keep reqspec  |\n|          |                        | pointing that AZ                       |\n+----------+------------------------+----------------------------------------+\n| With AZ  | AZ                     | Schedule to the new AZ, update the     |\n|          |                        | reqspec.AZ to the new AZ               |\n+----------+------------------------+----------------------------------------+\n\nProposed new behavior:\n\n+----------+---------------------------+-------+-----------------------------+\n| Boot     | Unshelve after offload AZ | Host  | Result                      |\n+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d+\n|  No AZ   | No AZ or AZ\u003dnull          | No    | Free scheduling,            |\n|          |                           |       | reqspec.AZ\u003dNone             |\n+----------+---------------------------+-------+-----------------------------+\n|  No AZ   | No AZ or AZ\u003dnull          | Host1 | Schedule to host1,          |\n|          |                           |       | reqspec.AZ\u003dNone             |\n+----------+---------------------------+-------+-----------------------------+\n|  No AZ   | AZ\u003d\"AZ1\"                  | No    | Schedule to AZ1,            |\n|          |                           |       | reqspec.AZ\u003d\"AZ1\"            |\n+----------+---------------------------+-------+-----------------------------+\n|  No AZ   | AZ\u003d\"AZ1\"                  | Host1 | Verify that host1 in AZ1,   |\n|          |                           |       | or (3). Schedule to         |\n|          |                           |       | host1, reqspec.AZ\u003d\"AZ1\"     |\n+----------+---------------------------+-------+-----------------------------+\n|  AZ1     | No AZ                     | No    | Schedule to AZ1,            |\n|          |                           |       | reqspec.AZ\u003d\"AZ1\"            |\n+----------+---------------------------+-------+-----------------------------+\n|  AZ1     | AZ\u003dnull                   | No    | Free scheduling,            |\n|          |                           |       | reqspec.AZ\u003dNone             |\n+----------+---------------------------+-------+-----------------------------+\n|  AZ1     | No AZ                     | Host1 | If host1 is in AZ1,         |\n|          |                           |       | then schedule to host1,     |\n|          |                           |       | reqspec.AZ\u003d\"AZ1\", otherwise |\n|          |                           |       | reject the request (1)      |\n+----------+---------------------------+-------+-----------------------------+\n|  AZ1     | AZ\u003dnull                   | Host1 | Schedule to host1,          |\n|          |                           |       | reqspec.AZ\u003dNone             |\n+----------+---------------------------+-------+-----------------------------+\n|  AZ1     | AZ\u003d\"AZ2\"                  | No    | Schedule to AZ2,            |\n|          |                           |       | reqspec.AZ\u003d\"AZ2\"            |\n+----------+---------------------------+-------+-----------------------------+\n|  AZ1     | AZ\u003d\"AZ2\"                  | Host1 | If host1 in AZ2 then        |\n|          |                           |       | schedule to host1,          |\n|          |                           |       | reqspec.AZ\u003d\"AZ2\",           |\n|          |                           |       | otherwise reject (1)        |\n+----------+---------------------------+-------+-----------------------------+\n```\n\nand yes i do think this should be a single micorverion for that addition an that we should do that at the same time.\n\nthis is also why i ask for the changes to pass an az to be it onw spec orginally.\n\ni really dont think the paramters or bevhiro shoudl differ per endpoint or move opertion.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6300e1a912318649bb30107e7ec1131aaa29091e","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7710ff33_e5af0d06","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"b4d96759_09903b19","updated":"2026-10-21 13:49:54.000000000","message":"As noted above, shelve doesn\u0027t actually behave any differently here, it just doesn\u0027t matter because the instance isn\u0027t running. We set the pin before we cast the unshelve to the compute. If the compute fails, it doesn\u0027t actually revert the pin at that point (because it can\u0027t). All it does it revert the pin if we fail to schedule or do some other setup. During a live migration, the instance will end up in one or the other and we don\u0027t have the luxury that shelve has of leaving a stale pin for a non-running instance that can just be arbirarily reset on retry.\n\nAnd to be honest, the complexity of the above table seems like a bug not a feature to me. It\u0027s quite the \"what will happen to my instance\" eye chart.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d49e9698e8b25cc5e401c999091d52eff4b80263","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."}],"source_content_type":"text/x-rst","patch_set":1,"id":"2b5411aa_2516cbc0","line":99,"range":{"start_line":99,"start_character":24,"end_line":99,"end_character":46},"in_reply_to":"d9f82bda_b595a00b","updated":"2026-10-21 15:11:38.000000000","message":"\u003e im also kind of ok with the pin not being reverted.\n\nFor live migration? The pin not being reverted means we\u0027ve pinned the instance to an AZ it is not running in. That does not seem like good UX to me.\n\n\u003e i think that is what im going to propose on teh watcher side if we do not just delegate this to nova becasue i dont think we shoudl be guessign why the migration failed if the vm end up in error.\n\u003e \n\u003e if the vem is active on the souce node when the migraiton goes to failled we could repin but the semaitcs will be complex and it not clear this shoudl be a policy decsion left to an adimin in that case.\n\u003e \n\u003e waht i really want is uniformity betwen the move operations so that operator do nto have to undersnad howe ver of them differs.\n\n\"Unpin first, then migrate and re-pin later\" works for every case. So if uniformity is what you want, that\u0027s the most universal behavior I think.\n\n\u003e im not married to the idea that it has to be exactly like unshleve but that cold migrate, live migrate, unshelve and evacuated shoudl all provide the same mechainiums to specifiy a desired destinatnon (host and/or az) adn that we have effectivly the same sematics for each opertion.\n\nThat involves a change to unshelve, AFAICT. To me, unshelve is different enough that I don\u0027t really care that the behavior is the same as the other operations. I also don\u0027t think that we\u0027ve ever said we\u0027d tie a whole lot of change for several independent operations together as a \"all or nothing\" sort of API change, so I\u0027m really resistant to holding the (already implemented) AZ part of this up for the other operations to reach parity. If you\u0027re -2 on doing this incrementally can you be really clear about it?\n\nI\u0027m fine with all the destination AZ semantics being the same across the actual move operations of course, but those semantics have to be reasonably doable for  all of them and fundamental change to the way they work or the way cells work is not something I think is worth the discrepancy.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fefec958_023fe9c8","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"updated":"2026-09-30 20:22:09.000000000","message":"so this shoudl probly be its own small spec since it a generic improemtn that is unrelated to the core of this feature.\n\nas you know as well as i do cells and AZs are two completly ortoganal ways to slice a nova deployemtn.\n\nso i think adding a new microversion just for destination az in its won spec woudl make sesne also if we do add it i asked previous when we added it for unhslve that in the futre we add it for cold-migrate/resize if we add it for live migrate\n\nideally with the same pining/unpinnng bevhiro as docuemtned in \nhttps://specs.openstack.org/openstack/nova-specs/specs/zed/implemented/unshelve-to-host.html#proposed-change\n\nso that all our move operation are consitent.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e369c28dc67fb23b486b822df2be859ed364c0f6","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6024c410_cc08fb76","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"103dec95_025ca79d","updated":"2026-10-09 15:27:31.000000000","message":"the az addtion i think shoudl be done first in its own micrvrion before any of the rest of the work. it should be added before the new v2 api if we go that way in either case.\n\nhaving it be its own spec was to make sure we had alignemnt on that addtion early so we could implment and commit that early rather then dealying it until this much larger spec is ready to merge.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"aee324ae_f3cf1be9","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"14904686_31347e23","updated":"2026-10-08 17:23:57.000000000","message":"Resolving this because the solution (if we want) is to have a separate parallel spec for making v1 take an AZ, but it\u0027ll stay here regardless.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"14904686_31347e23","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"18c3b0cb_be46eea1","updated":"2026-10-08 14:23:45.000000000","message":"It can, but it\u0027s more work and sequencing of course.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ae5307afef82617b7ed40c3b6aabc5a193929b76","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e9fe1010_2951f2fb","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"18c3b0cb_be46eea1","updated":"2026-10-08 17:47:34.000000000","message":"yes that is why i asked for the addtion of teh AZ filed to be in its own spec and done seperatly first but if we have a v2 api then i woudl obviously want that to be incldued form day 0.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06c07215266e4e68e1b5d1532f6dd4f192b50c1c","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"95738419_e8105243","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"2d60f5c9_10f8c985","updated":"2026-10-05 15:41:32.000000000","message":"It\u0027s pretty minor to support this and is alread part of the PoC code. We just modify the in-memory ReqSpec we pass to scheduler which never gets re-persisted and thus gets the normal filtering as if the user had asked for it. The up-front policy checking for \"can this move or is this limited\" has to be there anyway.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"68fcc256d771013fd65c4ac2d3e1123475607705","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6812f130_865aa4e6","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"6024c410_cc08fb76","updated":"2026-10-21 01:31:32.000000000","message":"+1 on adding AZ things as part of the initial version itself. Honestly, I am less worried about providing the AZ support in v1 as we have a workaround for that by pin/unpin before migration. if we are going to deprecate v1 then I will say let\u0027s freeze and add improvements in v2 APi itself. But anyway, I will not be against it if we want to add AZ support in v1 also, but yes, as a separate spec.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1b8d4f5d56f7cd4cd407ddb0a9a75dd630c9cc10","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e298bceb_b728c836","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"95738419_e8105243","updated":"2026-10-05 16:10:33.000000000","message":"yes this shoudl be prety easy to supprot which is why i was suggeting it could be done as a seperat small spec first just to add that parmater and hook it up to the request spec\n\nthe destination object can already hold the value we just dont have a way to pass it in the request.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bf513ec3_648ddc82","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"a93734ed_56794af6","updated":"2026-10-01 17:23:49.000000000","message":"While I agree this part could be split out from this spec to reduce the overall scope, I can also see that given this is version 0 of a brand new API, this parameter is just part of version 0.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"23b89f58a657b9c51a93e7b579dea1ce9760c31e","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"def48361_7ce95f26","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"bf513ec3_648ddc82","updated":"2026-10-01 17:57:50.000000000","message":"Right, I surely would not want to immediately rev this new API for a thing we want to include. Since I am positioning this as a sort of state reset, I want the API to look like what we want now, and thus not bringing baggage from the past (i.e. `block_migration`) nor skimping on table-stakes things we know we want to do like AZs.\n\nIf this was just an evolution of the existing API, then I\u0027d certainly say adding AZ targeting can/should go first.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2d60f5c9_10f8c985","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"def48361_7ce95f26","updated":"2026-10-05 14:23:55.000000000","message":"yeah, I don\u0027t want to nitpick on the format of the paperwork, I do care more about the review requirements for such large implementation, as it will add another stack.\nIf we go iteratively by adding a microversion on that new field, I\u0027m cool with, I just don\u0027t want to hold the whole cross-cell live-migration effort to merge if we start to nitpick on that AZ thing.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"18c3b0cb_be46eea1","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"e298bceb_b728c836","updated":"2026-10-08 13:03:22.000000000","message":"I feel like this can be resolved with\n* a new spec to add dest AZ to v1\n* continue adding dest AZ to v2 here in this spec\n\nThe two thing can be executed in parallel","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"103dec95_025ca79d","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"e9fe1010_2951f2fb","updated":"2026-10-09 08:29:36.000000000","message":"from a paperwork perspective, I\u0027m fine with this spec covering both the parity effort (to create another endpoint) and adding the AZ field.\nMy only concern is about the potential risk of slipping the code merge during this cycle if we\u0027re wanting to boil the ocean but after having written that comment, I now have better visibility on the changes and can safely accept the AZ field addition as something we can do during this cycle. Later, if we rush, we could drop it from the cycle but that\u0027s not needed now. Could we mark this as resolved ?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":96,"context_line":" - The `block_migration` parameter is not accepted and the behavior of ``auto``"},{"line_number":97,"context_line":"   will be assumed."},{"line_number":98,"context_line":" - The ``disk_over_commit`` parameter is not accepted"},{"line_number":99,"context_line":" - A new parameter of ``dest_availability_zone`` will be accepted which, if"},{"line_number":100,"context_line":"   present, will be used to scope the scheduling to only hosts within that AZ."},{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a93734ed_56794af6","line":102,"range":{"start_line":99,"start_character":0,"end_line":102,"end_character":30},"in_reply_to":"fefec958_023fe9c8","updated":"2026-10-01 16:26:15.000000000","message":"\u003e so this shoudl probly be its own small spec since it a generic improemtn that is unrelated to the core of this feature.\n\nThat would be true if we\u0027re talking about a single API, but I\u0027m not. But as noted above, if we did want to do that, we\u0027d need (or want) to serialize that in front of this work as once we made the cutover to \"2.106 means live migration is the new path\" we\u0027d be stuck. My proposal here and PoC has this built in to the new op and if we want to add more functions to v1 then we can do that separately.\n\n\u003e as you know as well as i do cells and AZs are two completly ortoganal ways to slice a nova deployemtn.\n\u003e \n\u003e so i think adding a new microversion just for destination az in its won spec woudl make sesne also if we do add it i asked previous when we added it for unhslve that in the futre we add it for cold-migrate/resize if we add it for live migrate\n\nYep, but right now live migration either requires them to pick a host or let the scheduler decide. If you\u0027re trying to clear out a cell or AZ, that\u0027s a lot of hand-picking of hosts.\n\n\u003e ideally with the same pining/unpinnng bevhiro as docuemtned in \n\u003e https://specs.openstack.org/openstack/nova-specs/specs/zed/implemented/unshelve-to-host.html#proposed-change\n\u003e \n\u003e so that all our move operation are consitent.\n\nWell, neither the current nor this proposed operation can really support targeted live migration where a pin gets changed because there\u0027s nothing left at the end to notice that it has completed with access to change the pin. Perhaps more discussion about that below.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"},{"line_number":106,"context_line":"different ``dest_availability_zone``. Such a request will be rejected. An"},{"line_number":107,"context_line":"operator must first remove the existing pin before migrating the instance to a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d176a645_30107742","line":104,"updated":"2026-10-08 13:03:22.000000000","message":"how does the new API behave if neither host nor dest AZ is provided in the API call? Will it\n* select a new host in the instance\u0027s current cell\n* select a new host in all cells\n\nAlso what happens when host is provided dest AZ is not provided, and the host is outside of the instance\u0027s current AZ?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"212aff88b57fd4929827036de3b58242f613f956","unresolved":true,"context_lines":[{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"},{"line_number":106,"context_line":"different ``dest_availability_zone``. Such a request will be rejected. An"},{"line_number":107,"context_line":"operator must first remove the existing pin before migrating the instance to a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"630e6f7c_6be29399","line":104,"in_reply_to":"442def2e_1c00335a","updated":"2026-10-08 18:17:31.000000000","message":"Ah, perfect. I hadn\u0027t even gone down the path of looking yet. But sounds like we\u0027re in agreement on just the weigher (if allowed to consider outside the cell via policy) and it\u0027s already there, so cool.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6f2885410f23dd57435224c86d4243dab9df10db","unresolved":false,"context_lines":[{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"},{"line_number":106,"context_line":"different ``dest_availability_zone``. Such a request will be rejected. An"},{"line_number":107,"context_line":"operator must first remove the existing pin before migrating the instance to a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e1546d0f_f88620b0","line":104,"in_reply_to":"630e6f7c_6be29399","updated":"2026-10-15 19:23:47.000000000","message":"Done","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"},{"line_number":106,"context_line":"different ``dest_availability_zone``. Such a request will be rejected. An"},{"line_number":107,"context_line":"operator must first remove the existing pin before migrating the instance to a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ef192198_b1fcde3b","line":104,"in_reply_to":"d176a645_30107742","updated":"2026-10-08 14:23:45.000000000","message":"\u003e how does the new API behave if neither host nor dest AZ is provided in the API call? Will it\n\u003e * select a new host in the instance\u0027s current cell\n\u003e * select a new host in all cells\n\nRight now in my PoC it\u0027s not constrained so technically the second. I meant to have another \"open question\" here about whether we default to never moving cells unless you specifically ask with an AZ or a destination host, or we just weigh the same-cell hosts higher.\n\nWe have a couple of customers that want to not align their AZs and cells. Meaning they want 2+ cells per AZ. If we don\u0027t to cross cell boundaries unless you specify a host/AZ then it becomes less useful because you end up doing the scheduling yourself. Thus I think I\u0027d go the weigher route and maybe default it very high.\n\n\u003e Also what happens when host is provided dest AZ is not provided, and the host is outside of the instance\u0027s current AZ?\n\nIf it\u0027s pinned you mean? It\u0027ll be the same as today, We\u0027ll get no candidates.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ae5307afef82617b7ed40c3b6aabc5a193929b76","unresolved":true,"context_lines":[{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"},{"line_number":106,"context_line":"different ``dest_availability_zone``. Such a request will be rejected. An"},{"line_number":107,"context_line":"operator must first remove the existing pin before migrating the instance to a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"442def2e_1c00335a","line":104,"in_reply_to":"d176a645_30107742","updated":"2026-10-08 17:47:34.000000000","message":"for cold migrate we have a weigher that stongly preferes the same cell.\nhttps://github.com/openstack/nova/blob/master/nova/scheduler/weights/cross_cell.py\n\ni woudl expect that if no prefence is expressed in teh request\nand there is no other limaition on the vms movement that we would jsut leave that handel it\n\n\nso if the only host that it coudl move too was in a diffent cell it would be allowed too select that but wiht a default cost of 1000000.0 that is very unlikely to ever happne unless you disable all host in the current cell.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":101,"context_line":"   If ``host`` is also provided, the operation will fail if the specified host"},{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"},{"line_number":106,"context_line":"different ``dest_availability_zone``. Such a request will be rejected. An"},{"line_number":107,"context_line":"operator must first remove the existing pin before migrating the instance to a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b79b97f3_f0b3d168","line":104,"in_reply_to":"ef192198_b1fcde3b","updated":"2026-10-08 17:23:57.000000000","message":"Added the missing section about scheduling preferences and added a note about the host being outside the pinned AZ.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":false,"context_lines":[{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"},{"line_number":106,"context_line":"different ``dest_availability_zone``. Such a request will be rejected. An"},{"line_number":107,"context_line":"operator must first remove the existing pin before migrating the instance to a"},{"line_number":108,"context_line":"different availability zone. This avoids retaining a stale pin after the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"27f9602d_8784305d","line":105,"range":{"start_line":105,"start_character":71,"end_line":105,"end_character":75},"updated":"2026-10-08 13:03:22.000000000","message":"femtonit: why does my brain wants to write migrated to instead of migrated with?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":false,"context_lines":[{"line_number":102,"context_line":"   is not in the specified AZ."},{"line_number":103,"context_line":"  - The async behavior of 2.34 and later will be assumed."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"An instance that has a ``pinned_availability_zone`` cannot be migrated with a"},{"line_number":106,"context_line":"different ``dest_availability_zone``. Such a request will be rejected. An"},{"line_number":107,"context_line":"operator must first remove the existing pin before migrating the instance to a"},{"line_number":108,"context_line":"different availability zone. This avoids retaining a stale pin after the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d249d57d_805628cb","line":105,"range":{"start_line":105,"start_character":71,"end_line":105,"end_character":75},"in_reply_to":"27f9602d_8784305d","updated":"2026-10-08 14:23:45.000000000","message":"\"to\" is correct, I will fix.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":118,"context_line":"the coordination ahead of time."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"In the new mode, the conductor will be responsible for collecting information"},{"line_number":121,"context_line":"from the compute nodes and (the check phases) as it can talk to both. It will"},{"line_number":122,"context_line":"also be responsible for pre-creating the instance records in the destination"},{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1e9bb8ac_6194d972","line":121,"range":{"start_line":121,"start_character":22,"end_line":121,"end_character":45},"updated":"2026-10-08 13:03:22.000000000","message":"femtonit: that \"and\" there confuses me. Is this what you mean?:\n\nthe conductor will be responsible for collecting information from the compute nodes (the check phases) as it can talk to both.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":118,"context_line":"the coordination ahead of time."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"In the new mode, the conductor will be responsible for collecting information"},{"line_number":121,"context_line":"from the compute nodes and (the check phases) as it can talk to both. It will"},{"line_number":122,"context_line":"also be responsible for pre-creating the instance records in the destination"},{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b69b9ee1_ba5bef82","line":121,"range":{"start_line":121,"start_character":22,"end_line":121,"end_character":45},"in_reply_to":"1e9bb8ac_6194d972","updated":"2026-10-08 14:23:45.000000000","message":"Yep, an \"english merge conflict\" while editing I think :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":118,"context_line":"the coordination ahead of time."},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"In the new mode, the conductor will be responsible for collecting information"},{"line_number":121,"context_line":"from the compute nodes and (the check phases) as it can talk to both. It will"},{"line_number":122,"context_line":"also be responsible for pre-creating the instance records in the destination"},{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"}],"source_content_type":"text/x-rst","patch_set":1,"id":"60253722_4d541add","line":121,"range":{"start_line":121,"start_character":22,"end_line":121,"end_character":45},"in_reply_to":"b69b9ee1_ba5bef82","updated":"2026-10-08 17:23:57.000000000","message":"Done","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":true,"context_lines":[{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"},{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"}],"source_content_type":"text/x-rst","patch_set":1,"id":"af754622_af3357e5","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":61},"updated":"2026-10-05 14:23:55.000000000","message":"will the source compute service be responsible for doing a pre-flight check verifying that QEMU/libvirt can perform the live-migration or will we handle that only when we start the migration ?\nI mean, cross-cell live-migration also implies that source and target computes can communicate between each others, depending on what the operator configured for the URI, the TLS encryption or any tunnel. This may be different across cells compared to intra-cell, right?\n\n//later I\u0027ve read the whole spec but you don\u0027t mention whether we would continue to support existing [libvirt] config knobs for migration or if you plan to create new ones. Based on that I\u0027m assuming you plan to reuse the existing ones, but then I feel our operators may need a way to tweak nova to ask for tunneled live-migrations if those are cross-cell (just a thought)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"edc59686f8f5bfcf4da66489d3d16ac699a7ffa1","unresolved":true,"context_lines":[{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"},{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c82bb5b3_3d332e0b","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":61},"in_reply_to":"0a32a4a3_be4d27d2","updated":"2026-10-05 16:27:45.000000000","message":"\u003e with that said i belvie we currently alwsy need ssh confictivty to copy the console logs so maybe we could jsut try and open an ssh conenction iwth no command or do a keyscan to confirm we can conenct and bail early.\n\n... we could also be doing that today, so I don\u0027t think we need to make anything specifically about cross-cell or v2 live migration here.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"},{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"}],"source_content_type":"text/x-rst","patch_set":1,"id":"80e1c207_eaadf4ee","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":61},"in_reply_to":"78bd4a1f_04330c40","updated":"2026-10-08 17:23:57.000000000","message":"Added note in the security impact section per gibi\u0027s suggestion.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06c07215266e4e68e1b5d1532f6dd4f192b50c1c","unresolved":true,"context_lines":[{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"},{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"}],"source_content_type":"text/x-rst","patch_set":1,"id":"cf7a9877_feed07b2","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":61},"in_reply_to":"af754622_af3357e5","updated":"2026-10-05 15:41:32.000000000","message":"\u003e will the source compute service be responsible for doing a pre-flight check verifying that QEMU/libvirt can perform the live-migration or will we handle that only when we start the migration ?\n\nThat part happens mostly the same as it does today, with one exception and that is the source-\u003edest pre_live_migration call. Conductor does the `check_can_live_migrate_{source,destination}` calls up front of course. Then it does the equivalent of the pre_live_migration call to the destination and passes the results to the source to start the live migration (basically just as the old one did, but calling itself).\n\n\u003e I mean, cross-cell live-migration also implies that source and target computes can communicate between each others, depending on what the operator configured for the URI, the TLS encryption or any tunnel. This may be different across cells compared to intra-cell, right?\n\nIt could be, and that would be a requirement for anyone wanting to enable this of course - that the hypervisors have to be able to talk to each other like any other two you plan to migrate between. But, the handling of that failure would be the same as intra-cell when a migration fails to start because of network turbulence or mis-configuration.\n\n\u003e //later I\u0027ve read the whole spec but you don\u0027t mention whether we would continue to support existing [libvirt] config knobs for migration or if you plan to create new ones. Based on that I\u0027m assuming you plan to reuse the existing ones, but then I feel our operators may need a way to tweak nova to ask for tunneled live-migrations if those are cross-cell (just a thought)\n\nTunneled how, over SSH? I certainly don\u0027t want to mix that into this and I think you could argue that edge or distributed-compute deployments may want that sort of thing independent of cells. As above, I don\u0027t think we should prescribe any different behavior at the hypervisor layer for cross-cell other than RPC. In nova, cells do not imply/require availability differences, network isolation, etc. It\u0027s purely a DB/MQ sharding mechanism and so I wouldn\u0027t want to involve any other requirements (like tunneling, isolaton, 1:1 AZ mapping, etc) unless explicitly necessary.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"},{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"}],"source_content_type":"text/x-rst","patch_set":1,"id":"78bd4a1f_04330c40","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":61},"in_reply_to":"c82bb5b3_3d332e0b","updated":"2026-10-08 13:03:22.000000000","message":"+1 on stating libvirt-libvirt network connectivity as a requirement but do nothing else than error handling (as today). If somebody raises the \"but network isolation\" card, then we can point at site to site vpn (as Sean mentioned) or any fancy dynamic pinhole firewall implementation in telco :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1b8d4f5d56f7cd4cd407ddb0a9a75dd630c9cc10","unresolved":true,"context_lines":[{"line_number":123,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":124,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"},{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0a32a4a3_be4d27d2","line":126,"range":{"start_line":126,"start_character":0,"end_line":126,"end_character":61},"in_reply_to":"cf7a9877_feed07b2","updated":"2026-10-05 16:10:33.000000000","message":"for corss cell cold migration we chgoose to raise the bar and assume no direct network connectivty between the hypervioer, while that is useful in some cases i dont think that is a reasonable expection for corss cell live migration\n\nso form my perspecte we just have a prequestit that to use this feature your souce and destiantion hypervior must have approate networkign such that there live migrate adress is asseible form the other node\n\nthat can be done with native tls or ssh or the operator can configure a site to site vpn if they like all nova shoudl care about is that the qemu process can talk to each other and i dont think we need to go into too much detail on how.\n\ntehre are several ways to do that.\nif libvirt cant talk to the remote libvirt you will get an error at the migreate_to_url2 call or whatever it is when we defient the domain.\n\ni dont think nova need to check that earlier sicne we dont want to know how the operator has provide connectivity\n\nwith that said i belvie we currently alwsy need ssh confictivty to copy the console logs so maybe we could jsut try and open an ssh conenction iwth no command or do a keyscan to confirm we can conenct and bail early.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":true,"context_lines":[{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"},{"line_number":130,"context_line":"interfaces, tags, instance actions, and migration records. The destination"},{"line_number":131,"context_line":"instance remains hidden until the destination compute has confirmed the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c9e027de_ee76b3a0","line":128,"range":{"start_line":128,"start_character":28,"end_line":128,"end_character":78},"updated":"2026-10-05 14:23:55.000000000","message":"remind me why we can\u0027t follow the usual pattern which is to create a Migration object record matching the target and then only create the instance record once the migration is ending ?\n\nI mean, we already have a structure in place for migrations and I\u0027m afraid of us having to query two different DB structures depending whether it is a live migration across cells or inside one.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":false,"context_lines":[{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"},{"line_number":130,"context_line":"interfaces, tags, instance actions, and migration records. The destination"},{"line_number":131,"context_line":"instance remains hidden until the destination compute has confirmed the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"cafa4b4c_f35273dc","line":128,"range":{"start_line":128,"start_character":28,"end_line":128,"end_character":78},"in_reply_to":"2a6bd55c_f9d83c6d","updated":"2026-10-09 08:29:36.000000000","message":"I see, in order to minimize the code changes, we\u0027ll be reusing most of the existing plumbing, which all have assumptions about an existing instance record, gotcha.\nThanks for clarifying it.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"},{"line_number":130,"context_line":"interfaces, tags, instance actions, and migration records. The destination"},{"line_number":131,"context_line":"instance remains hidden until the destination compute has confirmed the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2a6bd55c_f9d83c6d","line":128,"range":{"start_line":128,"start_character":28,"end_line":128,"end_character":78},"in_reply_to":"8d796abc_5ec4ec91","updated":"2026-10-08 17:23:57.000000000","message":"In case it wasn\u0027t clear, the instance _and_ migration objects get created on the target side in the same way.\n\nI\u0027m marking this resolved as I think there\u0027s no option other than pre-creating the instance in the target cell in the same way cross-cell cold migration does today and there has been no further discussion here.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06c07215266e4e68e1b5d1532f6dd4f192b50c1c","unresolved":true,"context_lines":[{"line_number":125,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"},{"line_number":130,"context_line":"interfaces, tags, instance actions, and migration records. The destination"},{"line_number":131,"context_line":"instance remains hidden until the destination compute has confirmed the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8d796abc_5ec4ec91","line":128,"range":{"start_line":128,"start_character":28,"end_line":128,"end_character":78},"in_reply_to":"c9e027de_ee76b3a0","updated":"2026-10-05 15:41:32.000000000","message":"Have you looked over the cross-cell cold migration code? The nova-compute on the receiving end has to have an instance record in its database for us to do anything to it at all. For network (vif-plug) events, for migration setup calls, etc.\n\nHowever, we also can\u0027t create that stuff after the migration is complete because there\u0027s nothing at the top-level that is watching the whole thing, ready to do that patching up after the fact, Doing so would require a thread in conductor (nameles, somewhere in the superconductor workers) to follow it for potentially hours ready to finish the migration. See the other discussion here about why that\u0027s problematic.\n\n\u003e I mean, we already have a structure in place for migrations and I\u0027m afraid of us having to query two different DB structures depending whether it is a live migration across cells or inside one.\n\nWhat I have is pretty clean on the \"if cross cell, else normal\" case FWIW. If the migration is successful the source hard-deletes its instance and if it is not successful, the destination hard-deletes it instance. That\u0027s pretty much the only difference between a cross- and intra-cell migration in my proposed V2. Unlike in V1 where changes to the instance kinda happen in both places depending on which kind of failure we\u0027re cleaning up from.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"},{"line_number":130,"context_line":"interfaces, tags, instance actions, and migration records. The destination"},{"line_number":131,"context_line":"instance remains hidden until the destination compute has confirmed the"},{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3cadb3a1_9fd66d6f","line":129,"range":{"start_line":129,"start_character":7,"end_line":129,"end_character":13},"updated":"2026-09-30 20:22:09.000000000","message":"https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L425\n\nok that is used to hide the instance recored form the target cell form the rest api \nas is curretnly done for cross cell resize.\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/cross-cell-resize.html#super-conductor\n\non edgecase that comes to mind with this is the interfaction bettwen a user delete and admin live migrate\n\nhow do we handel that fro same cross cell  resize or normal live migrate today?\n\nthe source node will have the instance lock held during the migration so the delete can be unqueed form rabbit but it will block before actully doign the delete on the instnace lock.\n\nso the actions will be serialsied on the source compute owever it would be recived by the source cell, if the migration succeed the delete woudl fail or more likely succed without deleting the instnace because the record would nolonger be soruce cell.\n\ndo you intend to return a 409 during the corss cell migration phase?\n\nas far as im aware the only time we return a 409 for the server delete api today is if the instnace is locked. https://docs.openstack.org/api-ref/compute/#delete-server\n\ni dont actully think a 409 is vaild in this case as we cant require the use of a new api version for delete to work and changign the precondtions of delete would itself require a microverion currently they are as follows\n\n```\nPreconditions\n\nThe server must exist.\n\nAnyone can delete a server when the status of the server is not locked and when the policy allows.\n\nIf the server is locked, you must have administrator privileges to delete the server.\n```\n\nmy practical suggestion is delete on an instance that is live migrating (cross cell or intra cell) should call abort on the migration and then delete it form whichever cell it actully is in.\n\nthat may requrie havign the api call the super conductore to orchstrate that as well.\n\n\ni have not checked but i woudl expect delete to interup live mgiration and cross cell resize today, if it does nto that feels like an existing bug that shoudl be fixed first.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"},{"line_number":130,"context_line":"interfaces, tags, instance actions, and migration records. The destination"},{"line_number":131,"context_line":"instance remains hidden until the destination compute has confirmed the"},{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"}],"source_content_type":"text/x-rst","patch_set":1,"id":"cb5e6f31_2a844e18","line":129,"range":{"start_line":129,"start_character":7,"end_line":129,"end_character":13},"in_reply_to":"3cadb3a1_9fd66d6f","updated":"2026-10-01 16:26:15.000000000","message":"\u003e how do we handel that fro same cross cell  resize or normal live migrate today?\n\nWe\u0027ve got some functional tests for live migration related to this because it has been broken in the past. I\u0027ll have to look at them to see what the gotchas have been there in the past that are now patched up.\n\nFor v2, I\u0027m untangling a lot of fragility in the current flow by sending external events to both source and destination during the migration. For plugging currently the source waits for the event but makes a blocking RPC call to the destination which triggers the event, and both wait in lockstep until it comes in. In v2, I send those events to both so either can wait and receive such things.\n\nI haven\u0027t gotten into all the edge case mechanics with my v2 PoC yet, but doing the same for delete would make sense I think. If the migration is in progress and the instance is deleted, we\u0027ll notice at least when we go to finish (success or failure). The source will delete the migration\u0027s allocations which will tell the destination to abort regardless and assume the migration isn\u0027t happening. The source can then do whatever cleanup and exit. There\u0027s so much back-and-forth in the v1 flow at cleanup time that I feel pretty confident v2 will be cleaner in this respect. If the delete operation races on the rabbit bus and the migration finishes, it will hit both the source and destination and whichever one kept the instance will be able to do a normal delete.\n\n\u003e the source node will have the instance lock held during the migration so the delete can be unqueed form rabbit but it will block before actully doign the delete on the instnace lock.\n\nI don\u0027t think any locks actually relate here as the marking of the instance record as deleted is the thing that trips things up, if I recall.\n\n\u003e do you intend to return a 409 during the corss cell migration phase?\n\nFor delete? Delete should never not work, IMHO.\n\n\u003e as far as im aware the only time we return a 409 for the server delete api today is if the instnace is locked. https://docs.openstack.org/api-ref/compute/#delete-server\n\nSure, but this isn\u0027t the lock you\u0027re talking about above, right? This would be the only reason to refuse a delete, IMHO.\n\n\u003e my practical suggestion is delete on an instance that is live migrating (cross cell or intra cell) should call abort on the migration and then delete it form whichever cell it actully is in.\n\nI think that today the delete partially completes and can race with the handover such that the instance keeps running until the destination node notices and deletes it in the periodic. Since my v2 proposal ends up with both source and destination monitoring the migration process (in v1 the destination doesn\u0027t) I think there\u0027s more potential for a proper abort-and-cleanup if we make delete actually trigger abort.\n\n\u003e i have not checked but i woudl expect delete to interup live mgiration and cross cell resize today, if it does nto that feels like an existing bug that shoudl be fixed first.\n\nWhy would fixing a latent cross-cell resize bug unrelated to live migration need to be fixed _first_?","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e7233113f02289940e8b2ba01921b1dc939522d7","unresolved":true,"context_lines":[{"line_number":126,"context_line":"then will kick off the actual migration with the source node."},{"line_number":127,"context_line":""},{"line_number":128,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":129,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings, virtual"},{"line_number":130,"context_line":"interfaces, tags, instance actions, and migration records. The destination"},{"line_number":131,"context_line":"instance remains hidden until the destination compute has confirmed the"},{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b277f94c_b4ca2d67","line":129,"range":{"start_line":129,"start_character":7,"end_line":129,"end_character":13},"in_reply_to":"cb5e6f31_2a844e18","updated":"2026-10-21 14:35:22.000000000","message":"i was refering to the instnace lock\nif its locked by an admin  or member of the proejct you will get a 409 if you try to delete it until the instnace is unlocked.\n\nadn im not sayign we shoudl nessiarly fix cross cell clold miggration fisrt\nwhat i am saying is we shoudl not knowingly extend the problemtic behvior to cross cell live mgiratne\n\nso yes i think it woudl be good for delete tor either triger live mgiration abort (regarless of how it was started or if it crosses cells)\n\nor refuse to do a partal delete that could leave the vm runign on teh destination hypervior when its deleted.\n\nwe do have the runnign deleted isntance preodic which default to reap\nhttps://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.running_deleted_instance_action\nbut if we ended up deitng the instance recored form the cell db that will not touch the vm.\n\nthat will only deleve the vm if the instnace recored is in teh cell db and markd as deleted\n\nif we hard delete the row instead of soft deleting it that wont clean it up.\n\nhttps://bugs.launchpad.net/nova/+bug/1820802\n\nso \nhttps://review.opendev.org/c/openstack/nova-specs/+/1008081/1..3/specs/2027.1/approved/cross-cell-live-migration.rst#172\nis problematic.\n\nunless we abort the migration at the libvirt level the vm can still move while we are deleting the vm.\n\nby the way im also aware that we do not want to prevent the vm form beign deleted just because the task_state!\u003dnone because they shoudl be able ot delete it if its stuck in any intermedary state.\n\nwe just need to be sure that if they asked for it to be deleted it is regardess of which host or cell it was in a the time.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"},{"line_number":133,"context_line":"will be hard-deleted."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"The destination compute node will take a more active role in the migration in"},{"line_number":136,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"},{"line_number":137,"context_line":"it to expect an incoming migration. Today we already \"record\" that a task is"},{"line_number":138,"context_line":"started so that we can avoid shutting down until a pending migration has"},{"line_number":139,"context_line":"completed. In the new flow this will start an actual thread that will monitor"},{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bc7242e6_6214c55e","line":141,"range":{"start_line":135,"start_character":0,"end_line":141,"end_character":11},"updated":"2026-09-30 20:22:09.000000000","message":"isnt this more or less the same spokey action at a distance or shadow rpc  you have argued against in the past.\n\nits not dissimlar form pooling the db for state chagne.\n\nwhy take that approach instead of having the source node return control to the conductor via simply returning form the migrate call instead of calling post live migrate itself.\n\nhave the conductor call the dest to start post live migrate.\ni.e. driving the interaction via the conductor and rpc rather then pooling\nseams a lot cleaner adn it does not wast a treah on both sides monitoring the migration.\n\nif we are aborting the migration via the api or because fo an error the souce rpc can simple return an exctption and the conductor can drive the destination cell cleanup.\n\nthat avoid burning a thread to monitor the job completion on both sides and it also avoid potiential race condtions.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"},{"line_number":133,"context_line":"will be hard-deleted."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"The destination compute node will take a more active role in the migration in"},{"line_number":136,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"},{"line_number":137,"context_line":"it to expect an incoming migration. Today we already \"record\" that a task is"},{"line_number":138,"context_line":"started so that we can avoid shutting down until a pending migration has"},{"line_number":139,"context_line":"completed. In the new flow this will start an actual thread that will monitor"},{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d035405c_79c25587","line":141,"range":{"start_line":135,"start_character":0,"end_line":141,"end_character":11},"in_reply_to":"0e591d3c_7353b507","updated":"2026-10-01 17:23:49.000000000","message":"This is very interesting points on why to do the monitoring on one of the computes vs the super conductor. My understanding of past dev summit discussions had been that super conductor would monitor everything but from what you have explained I can see the downsides I hadn\u0027t considered. I am always in support of minimizing scope so I find the idea of limiting monitors to only the nodes involved appealing. It is quite different than what I originally had in mind though.\n\nI think it\u0027s definitely worth including an extra paragraph here in the spec to explain the reasoning behind this design of monitoring this way instead of in the conductor.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7e0e2faf9abc7a71a90550d44f1f2cada713b991","unresolved":true,"context_lines":[{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"},{"line_number":133,"context_line":"will be hard-deleted."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"The destination compute node will take a more active role in the migration in"},{"line_number":136,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"},{"line_number":137,"context_line":"it to expect an incoming migration. Today we already \"record\" that a task is"},{"line_number":138,"context_line":"started so that we can avoid shutting down until a pending migration has"},{"line_number":139,"context_line":"completed. In the new flow this will start an actual thread that will monitor"},{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c06884bd_306c3a9c","line":141,"range":{"start_line":135,"start_character":0,"end_line":141,"end_character":11},"in_reply_to":"1d47f32d_328093b5","updated":"2026-10-01 18:13:37.000000000","message":"sorry, this should be \"I\u0027m *now* firmly in the camp of not...\" :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"},{"line_number":133,"context_line":"will be hard-deleted."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"The destination compute node will take a more active role in the migration in"},{"line_number":136,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"},{"line_number":137,"context_line":"it to expect an incoming migration. Today we already \"record\" that a task is"},{"line_number":138,"context_line":"started so that we can avoid shutting down until a pending migration has"},{"line_number":139,"context_line":"completed. In the new flow this will start an actual thread that will monitor"},{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0e591d3c_7353b507","line":141,"range":{"start_line":135,"start_character":0,"end_line":141,"end_character":11},"in_reply_to":"bc7242e6_6214c55e","updated":"2026-10-01 16:26:15.000000000","message":"\u003e isnt this more or less the same spokey action at a distance or shadow rpc  you have argued against in the past.\n\u003e \n\u003e its not dissimlar form pooling the db for state chagne.\n\nNo, there\u0027s no RPC involved here and thus categorically not what I\u0027ve previously objected to. Polling the DB for state change is definitely not spooky action at a distance and we do it in many places. When I\u0027ve used that term in the past I\u0027m referring specifically to not using an RPC bump to signal a behavioral change and then assuming that if the other side did something that looks like they\u0027re newer, that we can do the new thing. The proposal here is new RPC calls, with new semantics and a much more rigid definition of which node does what during the whole migration operation.\n\nIn this case, it\u0027s very well-defined what is going on... The destination is monitoring the process (today it doesn\u0027t until libvirt inserts a domain underneath it and then the source tells the destination \"this is yours now\") instead of ignoring things for most of the process. It is specifically involved in the setup, waiting for the migration\u0027s allocations to be deleted from the source or restored for the instance and then the follow-through. It\u0027s a very placement-centric view of that state of the world and provides a much more atomic cutover than a lot of chained blocking RPCs queued on a bus, potentially racing with other operations like delete as you note above. Being placement-centric fits well with the general trajectory of the project I think.\n\nHaving the destination aware of the migration from (roughly) start to finish makes cleanup of the destination node a lot more straightforward.\n\n\u003e why take that approach instead of having the source node return control to the conductor via simply returning form the migrate call instead of calling post live migrate itself.\n\nThe short answer is because I explored this implementation in depth and found plenty of reasons not to do it. Most significantly, a single headless conductor thread would have to be following this process for the entire duration. For real-world busy instances, that means hours. If a conductor worker gets restarted, it either needs to block for hours until this finishes or it loses track of the migration and things don\u0027t get cleaned up or finished. Since there\u0027s no way to know which headless/nameless conductor workers are silent dependencies of all your migrations, it becomes a really thorny operational problem not to disturb them. It basically increases the risk of disturbing the process by 50% as you now have another service/node required to stay up for the process to complete.\n\nFurther, that long-running conductor thread either has to have kicked off migration and then poll for status, either via RPC or in the database, OR it would need to use long-poll RPC to keep the call alive (again for hours) until it completes. If you move things like the port mapping cutover to conductor (which I initially did because it seemed architecturally appropriate) then you take the latency hit of that needing a reply over RPC to be delivered before it can happen.\n\nI went down that path thinking the elegant solution was to have conductor be the long-running thing, with the top-down view of everything so it could handle the process from beginning to end. I built that (I can push it up somewhere if you want) and it works for the happy path). After playing with it I came to realize there was real value in limiting the number of nodes involved in the migration, and to only the ones required to make it finish. Extending to just one more node, and especially a non-addressable one that should be ephemeral is a substantial risk. It complicates the overall process and also massively complicates the abort/force case as you literally can\u0027t send a message to that conductor that is orchestrating the job. It looks better on an architectural diagram, which is why I started there, but I think in practice it\u0027s not what we want.\n\n\u003e have the conductor call the dest to start post live migrate.\n\u003e i.e. driving the interaction via the conductor and rpc rather then pooling\n\u003e seams a lot cleaner adn it does not wast a treah on both sides monitoring the migration.\n\nI built it. It\u0027s fragile. Limiting the nodes involved to only the ones necessary is the safe approach. Making the api-db cutover between the cells is actually not hard at all, and allows the API to continue to address both of them until the thing completes one way or the other is eventually-consistent, efficient, and very much works like many of our migrate-on-read patterns elsewhere.\n\n\u003e that avoid burning a thread to monitor the job completion on both sides and it also avoid potiential race condtions.\n\nWe\u0027d be burning a thread in conductor instead of the destination. One we can\u0027t address, or know where it\u0027s running, how to avoid disturbing it, etc. We already have a bug where we _record_ the long-running task on the destination in v1 live migration and then lose track of it if the migration aborts on the destination, preventing graceful shutdown of the destination in that case. With a thread running that matches that task (like all the other recorded tasks we have) that problem goes away.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"},{"line_number":133,"context_line":"will be hard-deleted."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"The destination compute node will take a more active role in the migration in"},{"line_number":136,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"},{"line_number":137,"context_line":"it to expect an incoming migration. Today we already \"record\" that a task is"},{"line_number":138,"context_line":"started so that we can avoid shutting down until a pending migration has"},{"line_number":139,"context_line":"completed. In the new flow this will start an actual thread that will monitor"},{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fbf049a9_ee0fe780","line":141,"range":{"start_line":135,"start_character":0,"end_line":141,"end_character":11},"in_reply_to":"c06884bd_306c3a9c","updated":"2026-10-08 17:23:57.000000000","message":"Added a paragraph about the design decision not to involve conductor for the duration of the migration.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"23b89f58a657b9c51a93e7b579dea1ce9760c31e","unresolved":true,"context_lines":[{"line_number":132,"context_line":"migration completed. If the migration is rolled back, the destination records"},{"line_number":133,"context_line":"will be hard-deleted."},{"line_number":134,"context_line":""},{"line_number":135,"context_line":"The destination compute node will take a more active role in the migration in"},{"line_number":136,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"},{"line_number":137,"context_line":"it to expect an incoming migration. Today we already \"record\" that a task is"},{"line_number":138,"context_line":"started so that we can avoid shutting down until a pending migration has"},{"line_number":139,"context_line":"completed. In the new flow this will start an actual thread that will monitor"},{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1d47f32d_328093b5","line":141,"range":{"start_line":135,"start_character":0,"end_line":141,"end_character":11},"in_reply_to":"d035405c_79c25587","updated":"2026-10-01 17:57:50.000000000","message":"Yep, I had wanted the super-conductor to be the top-level monitor here, and that\u0027s why I built the first POC of this in that way (again I can push it up to non-gerrit if someone wants to look at it). It does work for cirros guests in the happy path. Once you try to get all the edge case functionals working and consider how we don\u0027t leave a mess if a conductor goes away or a migration takes 12 hours you start to see the problems.\n\nEven though it meant a total rewrite, I\u0027m not firmly in the camp of not making the fate of someone\u0027s VM depend on more nodes, especially ones with no name or no addressability :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"},{"line_number":145,"context_line":"placement allocations have been reverted, or because it saw a libvirt virtual"},{"line_number":146,"context_line":"machine appear and then disappear, etc. Local node cleanup when failure/abort"},{"line_number":147,"context_line":"has been determined will be done, and the source node will (as described below)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9e012c8d_730c8037","line":144,"range":{"start_line":143,"start_character":25,"end_line":144,"end_character":27},"updated":"2026-09-30 20:22:09.000000000","message":"again why?\n\nif the super conductor is the orchstrator of cross cell state by not have live migration abort not be a conductor rpc method\n\nif its a single or cross cell migration the condctor could call\nboth the souce and destination computes to notify them of the abort and allow them to do cleanup as needed.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"},{"line_number":145,"context_line":"placement allocations have been reverted, or because it saw a libvirt virtual"},{"line_number":146,"context_line":"machine appear and then disappear, etc. Local node cleanup when failure/abort"},{"line_number":147,"context_line":"has been determined will be done, and the source node will (as described below)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"744ca7a5_50818b20","line":144,"range":{"start_line":143,"start_character":25,"end_line":144,"end_character":27},"in_reply_to":"48e3e071_d6051c47","updated":"2026-10-08 17:23:57.000000000","message":"I think this is covered by the above important point of not relying on an unaddressable conductor thread to survive until the end.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":140,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":141,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":142,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":143,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":144,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"},{"line_number":145,"context_line":"placement allocations have been reverted, or because it saw a libvirt virtual"},{"line_number":146,"context_line":"machine appear and then disappear, etc. Local node cleanup when failure/abort"},{"line_number":147,"context_line":"has been determined will be done, and the source node will (as described below)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"48e3e071_d6051c47","line":144,"range":{"start_line":143,"start_character":25,"end_line":144,"end_character":27},"in_reply_to":"9e012c8d_730c8037","updated":"2026-10-01 16:26:15.000000000","message":"There are tons of edges in the current live migration where things are aborted, only one of which is the actual abort API call. Most of those involve decisions the source makes in isolation and result in calls from the source to the destination to do cleanup, and some don\u0027t but leave residue because they should (see our outstanding post-failure graceful shutdown bug).","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":164,"context_line":"by conductor ahead of time."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"It\u0027s important to clearly define each finalization step (both for successful"},{"line_number":167,"context_line":"completion and failure/rollback), and which of the compute nodes will own it."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Finalizing the process"},{"line_number":170,"context_line":"~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b36b414a_e292717a","line":167,"updated":"2026-10-08 13:03:22.000000000","message":"risking to stating the obvious an interesting edge case popped up in my mind reading the spec:\n\nThe difference when nova decides to rollback and have an ACTIVE VM on the source or when nova decide that the VM running state is lost as post-copy migration failed when the domain was already on the dest and therefore the only way is to roll forward to the dest but to a STOPPED state. Or are we rolling back to source today with a STOPPED state?\n\nI see that placement will be one / the source of truth about \"is it failed?\" global question. It will be interesting to see if we store enough information in placement for that. Like the mentioned difference between a user aborts the migration,or user deletes the VM, libvirt fails the migration in the middle.\n\nSimilarly can we rely on libvirt monitoring / events (today we monitor from the source and we will keep that afaik) on the dest as well? E.g. knowing when the two libvirts are now connected and transferring data or nowing that such connection is now broken form the dest perspective? I\"m not yet saying we need all this I\u0027m just curious if we have the possibility","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":164,"context_line":"by conductor ahead of time."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"It\u0027s important to clearly define each finalization step (both for successful"},{"line_number":167,"context_line":"completion and failure/rollback), and which of the compute nodes will own it."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Finalizing the process"},{"line_number":170,"context_line":"~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d31f967a_2815c1be","line":167,"in_reply_to":"94637528_6bdd6905","updated":"2026-10-08 17:23:57.000000000","message":"I\u0027m going to mark this resolved because I think there is sufficient mention a couple paragraphs above about expanding the handling. Namely:\n\n\u003e or because it saw a libvirt virtual machine appear and then disappear\n\nBut if you want more specifics here I can add them. Right now I don\u0027t have an error case where anything other than \"the source said success/fail via allocations\" so hopefully we can keep other things in our back pocket for robustification if/when we identify a gap that can be closed.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":164,"context_line":"by conductor ahead of time."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"It\u0027s important to clearly define each finalization step (both for successful"},{"line_number":167,"context_line":"completion and failure/rollback), and which of the compute nodes will own it."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Finalizing the process"},{"line_number":170,"context_line":"~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"94637528_6bdd6905","line":167,"in_reply_to":"b36b414a_e292717a","updated":"2026-10-08 14:23:45.000000000","message":"Yeah, these sorts of things are what we open up (at least potentially) by having the destination be a live monitor instead of just a passive part of the process. I haven\u0027t yet looked to see if or when we start getting events for the incoming domain from libvirt. I _think_ we see a domain pop up in \"migrating\" state fairly early, and I would guess maybe more/earlier when doing postcopy. These are things on my list (as I highlighted elsewhere here, to expand our \"did it work\" determination) but I haven\u0027t gotten there yet.\n\nI think that migration v1 does not provide us those opportunities in its current form.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6080756f46e9a1f5f51b3c55a2d62852ae4690b7","unresolved":false,"context_lines":[{"line_number":164,"context_line":"by conductor ahead of time."},{"line_number":165,"context_line":""},{"line_number":166,"context_line":"It\u0027s important to clearly define each finalization step (both for successful"},{"line_number":167,"context_line":"completion and failure/rollback), and which of the compute nodes will own it."},{"line_number":168,"context_line":""},{"line_number":169,"context_line":"Finalizing the process"},{"line_number":170,"context_line":"~~~~~~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d69232cc_9ed9a1b6","line":167,"in_reply_to":"d31f967a_2815c1be","updated":"2026-10-20 14:20:45.000000000","message":"I agree to move this to the implementation","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":176,"context_line":"hours-long) live migration has completed, we propose a lazy approach that will"},{"line_number":177,"context_line":"maintain access to the instance regardless of when and how a migration"},{"line_number":178,"context_line":"completed."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Currently, an instance may have only a single ``InstanceMapping`` record in the"},{"line_number":181,"context_line":"database and thus only one cell affiliation, because it may only be in one cell"},{"line_number":182,"context_line":"at a time. We propose to add a new field to ``InstanceMapping`` (called"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1257e836_90f8b103","line":179,"updated":"2026-09-30 20:22:09.000000000","message":"this also feels less then ideal, you are partly propsoign this to avoid the upcall to the api db and or super conductor to complete the migration but i kind fo feel like that woudl be preferable.\n\n\nso i think the design coudl be impvoed by havign a condutore to super conductor rpc api where by the compute woudl just call the local condutor to notify it of compelteion (success or faliure with 1 or 2 methods)\n\nif the cell condutors had the ablity to cast to the super conductor it could then finalise teh move operations.\n\nthat woudl effecivly mean makign the cell condutroe also supper conductors in that they woudl need access too the cell0 rabbit but would that really be a bad thing?\n\nit feels a lot better then this lazy mapiing update and if we have that ti woudl mean we can eventually suprpto auto cell registration without the computes knowign what cell they are in\n\nonly the cell condutor needs to knwo there local cell and if a new compute is registered on teh local cell it can notify the supper condutore and that cna update the host cell mappings in a similar way to the instnace_cell mapping your dicussign here.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":176,"context_line":"hours-long) live migration has completed, we propose a lazy approach that will"},{"line_number":177,"context_line":"maintain access to the instance regardless of when and how a migration"},{"line_number":178,"context_line":"completed."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Currently, an instance may have only a single ``InstanceMapping`` record in the"},{"line_number":181,"context_line":"database and thus only one cell affiliation, because it may only be in one cell"},{"line_number":182,"context_line":"at a time. We propose to add a new field to ``InstanceMapping`` (called"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4b919f08_d02849eb","line":179,"in_reply_to":"1257e836_90f8b103","updated":"2026-10-01 16:26:15.000000000","message":"Adding a mandatory upcall for live migration to work going forward feels like a massive step backwards to me. Requiring a compute-\u003econductor-\u003esupercond-\u003edestination call chain is also pretty heavy.\n\nFlattening the conductor hierarchy is a pretty major architectural change that I\u0027m not in favor of. I\u0027ve always hoped that would get to the point where a cell could be more autonomous such that the schema and cell conductors could be tied the lifecycle of the computes instead of the rest of the control plane. Effectively allowing the control plane to be upgraded before the cell conductors and compute DB schema. Moving away from cell conductors makes that a much harder thing in the future I think. But it\u0027s definitely not a change I\u0027m looking to make just to implement this feature.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":176,"context_line":"hours-long) live migration has completed, we propose a lazy approach that will"},{"line_number":177,"context_line":"maintain access to the instance regardless of when and how a migration"},{"line_number":178,"context_line":"completed."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Currently, an instance may have only a single ``InstanceMapping`` record in the"},{"line_number":181,"context_line":"database and thus only one cell affiliation, because it may only be in one cell"},{"line_number":182,"context_line":"at a time. We propose to add a new field to ``InstanceMapping`` (called"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7713dcd9_1bb7b397","line":179,"in_reply_to":"4b919f08_d02849eb","updated":"2026-10-08 17:23:57.000000000","message":"None of the other reviewers seemed to like the idea of adding anther upcall and I\u0027m definitely -2 on that idea (I\u0027d rather do other things before that). I\u0027ll add this as an option in alternatives just to record it of nothing else.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1a5ef49a_7b297f86","line":197,"range":{"start_line":194,"start_character":10,"end_line":197,"end_character":39},"updated":"2026-10-08 13:03:22.000000000","message":"\u003e We can do this in the same way for all migrations via the new\nmechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new\nmigrations that did not cross a cell boundary, and use that as the sentinel for\nthings like event dispatch (see below).\n\nWill that work? I mean if the old_cell_id \u003d\u003d cell_id and the instance is in that cell, then the api will always find the instance via the old_cell_id and therefore it will never switch to the cell_id and cleanup the old_cell_id to None.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":177,"context_line":"maintain access to the instance regardless of when and how a migration"},{"line_number":178,"context_line":"completed."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Currently, an instance may have only a single ``InstanceMapping`` record in the"},{"line_number":181,"context_line":"database and thus only one cell affiliation, because it may only be in one cell"},{"line_number":182,"context_line":"at a time. We propose to add a new field to ``InstanceMapping`` (called"},{"line_number":183,"context_line":"something like ``old_cell_id`` but maybe with a better name). This will"},{"line_number":184,"context_line":"indicate to the API (et al) that the instance *may* be in either the \"old\" cell"},{"line_number":185,"context_line":"or the \"new\" cell right now. During setup, the conductor will mutate the"},{"line_number":186,"context_line":"``InstanceMapping`` to set ``old_cell_id`` to reflect the cell the instance is"},{"line_number":187,"context_line":"currently in and the ``cell_id`` to reflect the new cell we expect the instance"},{"line_number":188,"context_line":"to migrate into. When the API goes to look up an instance (and thus resolves"},{"line_number":189,"context_line":"its cell) it will recognize the fact that it could be in either. It will first"},{"line_number":190,"context_line":"try looking up the cell in the \"old\" cell, and if present, will continue as if"},{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fd87c2bf_c2f03027","line":197,"range":{"start_line":180,"start_character":1,"end_line":197,"end_character":39},"updated":"2026-09-30 20:22:09.000000000","message":"im not really a fan of that.\n\nwe cant consier the live migration to be complete until teh cell mapping are updated so why not just use the migrtion recored to know which cell its in and atomicly update it it when completing the migration\n\ni dont think we need to change the db for this, if we wanted too change the db for this i would prefer to model this more like the multiple port bindign in neutron where we have the concept of an active mapping and inactive\n\nwe would relax the constrait on having only one mapping per isntance to only 1 active mapping per instance\n\non migration finalisation we woudl either delete the inactive mapping (pointing at the destination cell) or activate it and delete the old mapping in single atopic write transaction.\n\nas with neutron we can have the condutor create the inactive mapping prior to calling the sourece node to start the migration after check_can_live_migrate_souce has returne true and before live_migrate is called on teh souce node.\n\nhttps://docs.openstack.org/nova/2025.1/reference/live-migration.html","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"43de609d_4b954f1e","line":197,"range":{"start_line":194,"start_character":10,"end_line":197,"end_character":39},"in_reply_to":"1a5ef49a_7b297f86","updated":"2026-10-08 14:23:45.000000000","message":"Hah, good point, probably not without some more logic, I will think on this.\n\nSingle-cell migrations work with my PoC but I might have been getting lucky that they work for the singular network event but not another one, or not if I had raced with the migration.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9206a2a4_3843ace8","line":197,"range":{"start_line":194,"start_character":10,"end_line":197,"end_character":39},"in_reply_to":"43de609d_4b954f1e","updated":"2026-10-08 17:23:57.000000000","message":"I\u0027m going to remove the implementation-specific part of the text here and just say \"we\u0027ll send events to both source and destination for v2\" because that\u0027s the actual thing we need (cells aside). I\u0027ll look into how we want to actually decide to do that (which TBH could just be that we always send to both as it won\u0027t hurt anything) soon.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":177,"context_line":"maintain access to the instance regardless of when and how a migration"},{"line_number":178,"context_line":"completed."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Currently, an instance may have only a single ``InstanceMapping`` record in the"},{"line_number":181,"context_line":"database and thus only one cell affiliation, because it may only be in one cell"},{"line_number":182,"context_line":"at a time. We propose to add a new field to ``InstanceMapping`` (called"},{"line_number":183,"context_line":"something like ``old_cell_id`` but maybe with a better name). This will"},{"line_number":184,"context_line":"indicate to the API (et al) that the instance *may* be in either the \"old\" cell"},{"line_number":185,"context_line":"or the \"new\" cell right now. During setup, the conductor will mutate the"},{"line_number":186,"context_line":"``InstanceMapping`` to set ``old_cell_id`` to reflect the cell the instance is"},{"line_number":187,"context_line":"currently in and the ``cell_id`` to reflect the new cell we expect the instance"},{"line_number":188,"context_line":"to migrate into. When the API goes to look up an instance (and thus resolves"},{"line_number":189,"context_line":"its cell) it will recognize the fact that it could be in either. It will first"},{"line_number":190,"context_line":"try looking up the cell in the \"old\" cell, and if present, will continue as if"},{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"691520b8_c3dadb5a","line":197,"range":{"start_line":180,"start_character":1,"end_line":197,"end_character":39},"in_reply_to":"458947c1_cc5b59e1","updated":"2026-10-08 17:23:57.000000000","message":"If it\u0027s okay I\u0027m going to resolve this and we can argue about the name and the ordering of things in the implementation patches. I already have \"or a better name\" hedging in the text here.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6080756f46e9a1f5f51b3c55a2d62852ae4690b7","unresolved":false,"context_lines":[{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"694dd737_2e8a222d","line":197,"range":{"start_line":194,"start_character":10,"end_line":197,"end_character":39},"in_reply_to":"9206a2a4_3843ace8","updated":"2026-10-20 14:20:45.000000000","message":"ack","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":177,"context_line":"maintain access to the instance regardless of when and how a migration"},{"line_number":178,"context_line":"completed."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Currently, an instance may have only a single ``InstanceMapping`` record in the"},{"line_number":181,"context_line":"database and thus only one cell affiliation, because it may only be in one cell"},{"line_number":182,"context_line":"at a time. We propose to add a new field to ``InstanceMapping`` (called"},{"line_number":183,"context_line":"something like ``old_cell_id`` but maybe with a better name). This will"},{"line_number":184,"context_line":"indicate to the API (et al) that the instance *may* be in either the \"old\" cell"},{"line_number":185,"context_line":"or the \"new\" cell right now. During setup, the conductor will mutate the"},{"line_number":186,"context_line":"``InstanceMapping`` to set ``old_cell_id`` to reflect the cell the instance is"},{"line_number":187,"context_line":"currently in and the ``cell_id`` to reflect the new cell we expect the instance"},{"line_number":188,"context_line":"to migrate into. When the API goes to look up an instance (and thus resolves"},{"line_number":189,"context_line":"its cell) it will recognize the fact that it could be in either. It will first"},{"line_number":190,"context_line":"try looking up the cell in the \"old\" cell, and if present, will continue as if"},{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fdbf99c9_f13a0b30","line":197,"range":{"start_line":180,"start_character":1,"end_line":197,"end_character":39},"in_reply_to":"c1009aff_30f3fed8","updated":"2026-10-01 17:23:49.000000000","message":"I don\u0027t love the idea of a new `old_cell_id` column either 🫤 Is there any reason not to do the inverse and add `pending_cell_id` to be the new or intended next cell_id? That feels less weird to me than encoding an \"old\" one.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":177,"context_line":"maintain access to the instance regardless of when and how a migration"},{"line_number":178,"context_line":"completed."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Currently, an instance may have only a single ``InstanceMapping`` record in the"},{"line_number":181,"context_line":"database and thus only one cell affiliation, because it may only be in one cell"},{"line_number":182,"context_line":"at a time. We propose to add a new field to ``InstanceMapping`` (called"},{"line_number":183,"context_line":"something like ``old_cell_id`` but maybe with a better name). This will"},{"line_number":184,"context_line":"indicate to the API (et al) that the instance *may* be in either the \"old\" cell"},{"line_number":185,"context_line":"or the \"new\" cell right now. During setup, the conductor will mutate the"},{"line_number":186,"context_line":"``InstanceMapping`` to set ``old_cell_id`` to reflect the cell the instance is"},{"line_number":187,"context_line":"currently in and the ``cell_id`` to reflect the new cell we expect the instance"},{"line_number":188,"context_line":"to migrate into. When the API goes to look up an instance (and thus resolves"},{"line_number":189,"context_line":"its cell) it will recognize the fact that it could be in either. It will first"},{"line_number":190,"context_line":"try looking up the cell in the \"old\" cell, and if present, will continue as if"},{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c1009aff_30f3fed8","line":197,"range":{"start_line":180,"start_character":1,"end_line":197,"end_character":39},"in_reply_to":"fd87c2bf_c2f03027","updated":"2026-10-01 16:26:15.000000000","message":"\u003e im not really a fan of that.\n\u003e \n\u003e we cant consier the live migration to be complete until teh cell mapping are updated so why not just use the migrtion recored to know which cell its in and atomicly update it it when completing the migration\n\u003e \n\u003e i dont think we need to change the db for this, if we wanted too change the db for this i would prefer to model this more like the multiple port bindign in neutron where we have the concept of an active mapping and inactive\n\u003e \n\u003e we would relax the constrait on having only one mapping per isntance to only 1 active mapping per instance\n\nWe\u0027d need more change for that. We\u0027d need to drop the UNIQUE on the `instance_uuid`. We\u0027d need to add a column to know which one is primary and secondary. We\u0027d need a way to make sure you don\u0027t end up with 7 mappings after multiple failed things. I think we\u0027d end up with a lot more edge cases to handle. My PoC also uses the fact that both fields are populated to know that a v2 migration is going on and handles it the same way, even if the old and new cell ID are the same. It\u0027s nice symmetry.\n\n\u003e on migration finalisation we woudl either delete the inactive mapping (pointing at the destination cell) or activate it and delete the old mapping in single atopic write transaction.\n\nI don\u0027t think it\u0027s a benefit losing the current 1:1 mapping, but if people really think dropping that UNIQUE constraint is better then we can certainly do that instead. But we do need some sort of change if we\u0027re going to track the two places an instance can be.\n\nThe lazy update in practice works extremely well as there is zero latency between the actual cutover and the updating of the mapping. The api assumes it\u0027s in the old cell until it\u0027s not in the old cell anymore, in which case it\u0027s in the new cell. IIRC there\u0027s a dead spot in the cross-cell live migration where that isn\u0027t true because we can\u0027t simultaneously mark the new instance un-hidden, hard-delete the old one, and update the instance mapping. Letting the API sort of vector compute the right thing works better, IMHO. I would propose we make cross-cell cold migration work the same way after this to eliminate that dead spot.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"23b89f58a657b9c51a93e7b579dea1ce9760c31e","unresolved":true,"context_lines":[{"line_number":177,"context_line":"maintain access to the instance regardless of when and how a migration"},{"line_number":178,"context_line":"completed."},{"line_number":179,"context_line":""},{"line_number":180,"context_line":"Currently, an instance may have only a single ``InstanceMapping`` record in the"},{"line_number":181,"context_line":"database and thus only one cell affiliation, because it may only be in one cell"},{"line_number":182,"context_line":"at a time. We propose to add a new field to ``InstanceMapping`` (called"},{"line_number":183,"context_line":"something like ``old_cell_id`` but maybe with a better name). This will"},{"line_number":184,"context_line":"indicate to the API (et al) that the instance *may* be in either the \"old\" cell"},{"line_number":185,"context_line":"or the \"new\" cell right now. During setup, the conductor will mutate the"},{"line_number":186,"context_line":"``InstanceMapping`` to set ``old_cell_id`` to reflect the cell the instance is"},{"line_number":187,"context_line":"currently in and the ``cell_id`` to reflect the new cell we expect the instance"},{"line_number":188,"context_line":"to migrate into. When the API goes to look up an instance (and thus resolves"},{"line_number":189,"context_line":"its cell) it will recognize the fact that it could be in either. It will first"},{"line_number":190,"context_line":"try looking up the cell in the \"old\" cell, and if present, will continue as if"},{"line_number":191,"context_line":"that is the case. If it hits a `NotFound` there, it will try again but in the"},{"line_number":192,"context_line":"\"new\" cell. Assuming it finds it, it will update the ``InstanceMapping`` to"},{"line_number":193,"context_line":"``NULL`` out the ``old_cell_id`` and continue, knowing the migration has"},{"line_number":194,"context_line":"completed. We can do this in the same way for all migrations via the new"},{"line_number":195,"context_line":"mechansim, setting the ``old_cell_id`` to the same cell as ``cell_id`` for new"},{"line_number":196,"context_line":"migrations that did not cross a cell boundary, and use that as the sentinel for"},{"line_number":197,"context_line":"things like event dispatch (see below)."},{"line_number":198,"context_line":""},{"line_number":199,"context_line":"In order for this to work, all of the finalization work must be done by the"},{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"}],"source_content_type":"text/x-rst","patch_set":1,"id":"458947c1_cc5b59e1","line":197,"range":{"start_line":180,"start_character":1,"end_line":197,"end_character":39},"in_reply_to":"fdbf99c9_f13a0b30","updated":"2026-10-01 17:57:50.000000000","message":"I mean, they both accomplish the same thing, so no not really. I also don\u0027t love the \"old\" name here so we could certainly argue about that.\n\nHowever, the thinking here was that we position this as assuming the migration is likely to succeed. That means that we rewrite the InstanceMap (mostly) as it will look after the fact because we expect it to finish successfully. The lazy update becomes just a nuke of the old one once we don\u0027t find it there anymore. If we did what you propose then the lazy update becomes \"copy new to current and delete new\" which feels both more complicated and less like what we\u0027re sort of expecting to happen in the normal case. I certainly have a preference for the simpler and assuming-success pattern but it\u0027s not critical. I\u0027m going to push up the POC code early next week, which might convince you is cleaner this way, modulo the name. Can we leave this to the implementation as a detail since it\u0027s functionally the same?\n\n`original`, `previous`, `migrating_from`, `huckleberry`.. all potentially better names than `old` which I would consider.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"},{"line_number":201,"context_line":"that the only final resolution required is to flip the mapping."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"VIF plug events"},{"line_number":204,"context_line":"~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Currently the source compute waits for the VIF plug events that are triggered"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ecbb5108_006b37bc","line":203,"updated":"2026-10-08 13:03:22.000000000","message":"is there an issue with doc formatting? I don\u0027t see this subtitle or any other in the Proposed Change section in the html doc \n\nhttps://e5b34c37098a9ff04ce7-c2c178731190b96d718ae1e4710dfab3.ssl.cf5.rackcdn.com/openstack/3826b504b07449a0b6206fc86808f069/docs/specs/2027.1/approved/cross-cell-live-migration.html#proposed-change","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6f2885410f23dd57435224c86d4243dab9df10db","unresolved":false,"context_lines":[{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"},{"line_number":201,"context_line":"that the only final resolution required is to flip the mapping."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"VIF plug events"},{"line_number":204,"context_line":"~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Currently the source compute waits for the VIF plug events that are triggered"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9214744c_50ee9d86","line":203,"in_reply_to":"a9b91f33_0cb15a58","updated":"2026-10-15 19:23:47.000000000","message":"Done","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":true,"context_lines":[{"line_number":200,"context_line":"compute nodes (both for normal completion and the revert/rollback case) so"},{"line_number":201,"context_line":"that the only final resolution required is to flip the mapping."},{"line_number":202,"context_line":""},{"line_number":203,"context_line":"VIF plug events"},{"line_number":204,"context_line":"~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Currently the source compute waits for the VIF plug events that are triggered"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a9b91f33_0cb15a58","line":203,"in_reply_to":"ecbb5108_006b37bc","updated":"2026-10-08 14:23:45.000000000","message":"hmm, yeah, will look. I\u0027ve really only read it in text form :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":203,"context_line":"VIF plug events"},{"line_number":204,"context_line":"~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Currently the source compute waits for the VIF plug events that are triggered"},{"line_number":207,"context_line":"by neutron when we make the ``pre_live_migration`` call to the destination."},{"line_number":208,"context_line":"Since the source compute will not do that itself, it can\u0027t wait for them in"},{"line_number":209,"context_line":"a deterministic way."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Going forward, migrations that are initiated with this new API will have"},{"line_number":212,"context_line":"instance events sent (i.e. copied) to both source and destination nodes during"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d1c82a64_18ac3acf","line":209,"range":{"start_line":206,"start_character":1,"end_line":209,"end_character":20},"updated":"2026-09-30 20:22:09.000000000","message":"this is contole by a flag in the migrate_data retrun form the destiation host to the souce during pre_live_migrate\n\nthe current source node behvior where we wait for neutorn to notify the source node that hte networkign set up is complete is only used when usign the mutlipel port bidnign flow. we only supprot cross cell cold migrate when the nturon backend supprots mutliple port bidning and i would expect the same to be true for live migrate.\n\ni dont think we should remove this wait on  for neutron to notify nova that the ports are bound in general before we call driver.migrate\n\nthe migrate_data object that carreis the flag to contol this also has the pci address and other port binding information infromation requried to be able to generate the destination xml for libvirt.\n\nso the only realy option i see if you want to elimiatnt the src to dest rpc call in live_migrate is to move the call to pre_live_migrate to the conductor \n\nbut to do that reqruied first callign the souce node to create teh inital migrate_data object.\n\nif we look at \nhttps://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/cross-cell-resize.html#super-conductor\n\nspecifclly under `Prep Resize at Dest`\n\nyou can see that the prep_snapshot_based_resize_at_dest rpc which is the equivlent of pre_live_migration we create the destination port binding.\n\n\ncech_can_live_migrate_destination and check_can_live_migrate_souce\nare currently in the wrong order\nit might be possibel to swap them so that \n\ncheck_can_live_migrate_souce woudl call the souce node and get the partly constucted migrate_data obejct adn pass that to the destiantion via cech_can_live_migrate_destination then feed the fully constructed migrate_data object into the live_migrate call. but the spec does not cover that.\n\ncreating the port binidng in pre migration (live or cross cell resize)\nthis is partly to confirm that neturon will allow the port to be bound to the destination host btu we also set \"migrate_to\" in the the biding:profile so that neutron knwo which host the vm is moving too.\nwe set migrating_to for cold-migrate/resize as well so that neutron will not acidentlly send the vif plugged events for ports on the source host so its impoant to maintain this setup before calling libvirt to start the migration to prevent race condtions.\n\n\ndurign pre_live_migrate (on the desition host) the compute mangeer passes\nthe migrate data object to the driver so it can update it with the pci and numa claims and we then fiture out which flow we are usign an update the netowrking in neturon\n\nhttps://github.com/openstack/nova/blob/master/nova/compute/manager.py#L9160-L9162\nhttps://github.com/openstack/nova/blob/master/nova/compute/manager.py#L9164-L9181\n\nIf we drill into the libvirt drivers implmemtation you can see we call _pre_live_migration_plug_vifs form pre_live_migration\n\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L12201-L12202\n\nwhich in addtion to updating the migration data object with the relevnet pci adresses form the destiantion pci cleiam also calls os-vif or the legacy flow via plug_vifs\n\neffectivly what plug vifs is soing it create the tap devices, ovs port and or attaching the representor VFs for hardware offloaded ovs so that neutron can asynconosly bind the ports.\n\nhttps://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L12099-L12115\n\nall of that work and the sideefct that are reported via the migrate_data obejct still need to happen before we call the hypervisor to do the migration so simply sedign the copies of the event to both nodes does not really help.\n\nwe need to make sure the networkign is setup on the destion before we start the migration at the qemu level.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":203,"context_line":"VIF plug events"},{"line_number":204,"context_line":"~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Currently the source compute waits for the VIF plug events that are triggered"},{"line_number":207,"context_line":"by neutron when we make the ``pre_live_migration`` call to the destination."},{"line_number":208,"context_line":"Since the source compute will not do that itself, it can\u0027t wait for them in"},{"line_number":209,"context_line":"a deterministic way."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Going forward, migrations that are initiated with this new API will have"},{"line_number":212,"context_line":"instance events sent (i.e. copied) to both source and destination nodes during"}],"source_content_type":"text/x-rst","patch_set":1,"id":"08e5f79b_d754c2cc","line":209,"range":{"start_line":206,"start_character":1,"end_line":209,"end_character":20},"in_reply_to":"3783260a_ca906157","updated":"2026-10-08 17:23:57.000000000","message":"I don\u0027t think there\u0027s any action needed from this since we\u0027re keeping the neutron wait on the destination (with less janky plumbing than today). So I\u0027ll mark this as resolved.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":203,"context_line":"VIF plug events"},{"line_number":204,"context_line":"~~~~~~~~~~~~~~~"},{"line_number":205,"context_line":""},{"line_number":206,"context_line":"Currently the source compute waits for the VIF plug events that are triggered"},{"line_number":207,"context_line":"by neutron when we make the ``pre_live_migration`` call to the destination."},{"line_number":208,"context_line":"Since the source compute will not do that itself, it can\u0027t wait for them in"},{"line_number":209,"context_line":"a deterministic way."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"Going forward, migrations that are initiated with this new API will have"},{"line_number":212,"context_line":"instance events sent (i.e. copied) to both source and destination nodes during"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3783260a_ca906157","line":209,"range":{"start_line":206,"start_character":1,"end_line":209,"end_character":20},"in_reply_to":"d1c82a64_18ac3acf","updated":"2026-10-01 16:26:15.000000000","message":"The new plan still sets up the mapping ahead of time. The destination does this during the equivalent of pre_live_migration and it does so without a blocking call from source to dest where the destination does the mapping and the source receives the event. It\u0027s much cleaner and less confusing (especially for debugging) because the host doing the wait is the one doing the thing that triggers the event and is the one receiving the event.\n\nOther than that, nothing else has changed in what\u0027s being proposed here. The destination prepares, waits for the neutron event, the source migrates and converts to the dest mapping the instant the migration completes and the cleanup of whoever doesn\u0027t keep the instance happens on that node.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"2376bbc2d4705e1f4cde0e2fcec4bdddba649b56","unresolved":true,"context_lines":[{"line_number":215,"context_line":"Outstanding question: instance names"},{"line_number":216,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"There is a quirk in nova where we maintain and enforce the insance name in"},{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"380b5e16_2cbd77e0","line":218,"range":{"start_line":218,"start_character":59,"end_line":218,"end_character":66},"updated":"2026-10-01 17:23:49.000000000","message":"instance","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"23b89f58a657b9c51a93e7b579dea1ce9760c31e","unresolved":false,"context_lines":[{"line_number":215,"context_line":"Outstanding question: instance names"},{"line_number":216,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":217,"context_line":""},{"line_number":218,"context_line":"There is a quirk in nova where we maintain and enforce the insance name in"},{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"01cd7158_33220462","line":218,"range":{"start_line":218,"start_character":59,"end_line":218,"end_character":66},"in_reply_to":"380b5e16_2cbd77e0","updated":"2026-10-01 17:57:50.000000000","message":"Acknowledged","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"319dee8b_19a0a3a8","line":222,"updated":"2026-09-30 20:22:09.000000000","message":"right this is why i have wanted to update the defautl for that to the uuid for years\n\nthe reason we have not dont that was because of upgrade impact but perhasp now is a good time to revisit tyat.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":true,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0a954b14_cbf6f399","line":222,"updated":"2026-10-05 14:23:55.000000000","message":"tbc, this is a known issue already happening with cross-cell cold migrations, you\u0027re proposing to solve that other problem with that spec. I\u0027m not opposed to it, that\u0027s just yet another stack of changes to review, but I agree on the fact this is maybe the right opportunity to do it now.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06c07215266e4e68e1b5d1532f6dd4f192b50c1c","unresolved":true,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ae27d9e9_90c1b57c","line":222,"in_reply_to":"0a954b14_cbf6f399","updated":"2026-10-05 15:41:32.000000000","message":"I\u0027m not proposing to solve it in this spec. I\u0027m saying we can either document it as a requirement to use a uuid-based format template, or figure out a migration path to change it for everyone. But I\u0027m not adding that as a dependency.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"eeaa40a3_54132427","line":222,"in_reply_to":"1faad80e_00b67158","updated":"2026-10-08 17:23:57.000000000","message":"Changed the section from \"outstanding question\" to \"known issue\" and noted more explicitly that we won\u0027t be boiling that body of water synchronously here.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"ae5307afef82617b7ed40c3b6aabc5a193929b76","unresolved":true,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"989e1e52_720dc8cf","line":222,"in_reply_to":"1faad80e_00b67158","updated":"2026-10-08 17:47:34.000000000","message":"i actully think we can adress this sepereally \npart of it may even be a viald backportable bugfix\n\nthe part that will need a cycle or two is updating the default\n\nbut looking up the domain alwasy by its domain uuid (which is the instance uuid)\nis somethign we can do first. next we need to cofnirm that we are not using that for th instance state path (i do not beile we are but if we were we would need to acomidate that with for example a fallback to the db id) \n\nonce we have that macinary in place so we can find the local instnace resouce (domain/disk) we can evaulate if we woudl change the default.\n\nso for now yes just documenting the recommdation to use the uuid i think is fine.\nas long as we note this is not somethign that can be change on an exsting cloud.\n\nalthough it may be possibel to change this on an empyt cell.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a7f1599e_275573fe","line":222,"in_reply_to":"319dee8b_19a0a3a8","updated":"2026-10-01 16:26:15.000000000","message":"Yup :)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":false,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5972c39b_e837f6cb","line":222,"in_reply_to":"989e1e52_720dc8cf","updated":"2026-10-09 08:29:36.000000000","message":"Thanks Dan for moving it in the spec, that\u0027s clearer to me (marking it resolved then)","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5fb8fb56_a3cfd48f","line":222,"in_reply_to":"a7f1599e_275573fe","updated":"2026-10-08 17:23:57.000000000","message":"Acknowledged","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":219,"context_line":"libvirt, which by default is based on a configurable format that includes the"},{"line_number":220,"context_line":"database id. Since instances in adjacent cells will have overlapping ``id``"},{"line_number":221,"context_line":"fields, we must avoid collisions in some way as during migration the instance"},{"line_number":222,"context_line":"could land on a compute node that already has an instance with the same name."},{"line_number":223,"context_line":""},{"line_number":224,"context_line":"Ideally we would migrate away from this unsafe publication of private/internal"},{"line_number":225,"context_line":"IDs (as we have previously identified we should do). For greenfield deployments"}],"source_content_type":"text/x-rst","patch_set":1,"id":"1faad80e_00b67158","line":222,"in_reply_to":"ae27d9e9_90c1b57c","updated":"2026-10-08 13:03:22.000000000","message":"Lets be realistic. Document it that we recommend the uuid based settings or else :). I don\u0027t think we will have brainpower left in the cycle to think about a migration plan and implement it.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":227,"context_line":"stable and actually-unique format of ``instance-$UUID`` and deprecate the"},{"line_number":228,"context_line":"ability to control the name via config. For existing domains, we can rename"},{"line_number":229,"context_line":"them at hard reboot time, and we should probably start doing this sooner than"},{"line_number":230,"context_line":"later."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"During live migration, we are not allowed to simply generate a new name in the"},{"line_number":233,"context_line":"destination XML. However, the ``virsh`` command for live migration does have a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7e7fd497_afb075a6","line":230,"updated":"2026-09-30 20:22:09.000000000","message":"yes, i really really wanted to change this downstream and wanted to adopt `instance-$UUID`` as the default in antelope but we never got around to it so +1 on finally doing that.\n\nit also make s debuging a lot simpler.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":false,"context_lines":[{"line_number":227,"context_line":"stable and actually-unique format of ``instance-$UUID`` and deprecate the"},{"line_number":228,"context_line":"ability to control the name via config. For existing domains, we can rename"},{"line_number":229,"context_line":"them at hard reboot time, and we should probably start doing this sooner than"},{"line_number":230,"context_line":"later."},{"line_number":231,"context_line":""},{"line_number":232,"context_line":"During live migration, we are not allowed to simply generate a new name in the"},{"line_number":233,"context_line":"destination XML. However, the ``virsh`` command for live migration does have a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4cdcb259_17252c30","line":230,"in_reply_to":"7e7fd497_afb075a6","updated":"2026-10-01 16:26:15.000000000","message":"Acknowledged","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":235,"context_line":"for us to effect such a change in our own migration. If that is not possible"},{"line_number":236,"context_line":"for some reason then we may need to simply require operators to hard reboot"},{"line_number":237,"context_line":"their instances before they can be migrated across cells (or accept that the"},{"line_number":238,"context_line":"migration may fail due to a name conflict)."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Alternatives"},{"line_number":241,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3147a9b5_a7d7ed98","line":238,"updated":"2026-09-30 20:22:09.000000000","message":"if if i remmeber correctly the reason i had to revert out the overried to the uuid downstream was one the live migration update issue and 2 if you restarted the agent with vms on the host it broke hard reboot and other actions that use the template direclty\n\nhttps://github.com/openstack-k8s-operators/nova-operator/commit/8289cb089688011039620036f1c576abcf29344b#diff-2f09928534c8686d4f5f3db06dde824dd2857d2338c5850c24e13777cfc8ebd8R33\n\nhttps://github.com/openstack-k8s-operators/nova-operator/commit/406a798cef953255e171d3ae1d455f75d5e456a3#diff-2f09928534c8686d4f5f3db06dde824dd2857d2338c5850c24e13777cfc8ebd8L31\n\n\nwe can look up the domain via it uuid as far as im aware and we alwasy sett the uuid in teh domain to the isntace uuid\n\nwe made that chagne around liberty like 14 years ago to allow collected and other monintoring systems to correactle the livbirt domain stats with the nova instance.\n\nvirsh list allows you to print the uuid\n\nsean@icewind:~$ virsh list --uuid\nfe4a59fc-9def-4a42-87a0-d878244e5c52\na619f6b2-c000-40b3-9121-a012c4b6fecf\n227cfeb4-bf5c-4646-a7f3-8641efdea2da\na53c9608-b580-49e0-8210-22134eb20758\n\nand domain accpate the uuid in the id string as you noted\n\nsean@icewind:~$ virsh dumpxml --help\n  NAME\n    dumpxml - domain information in XML\n\n  SYNOPSIS\n    dumpxml \u003cdomain\u003e [--inactive] [--security-info] [--update-cpu] [--migratable]\n\n  DESCRIPTION\n    Output the domain information as an XML dump to stdout.\n\n  OPTIONS\n    [--domain] \u003cstring\u003e  domain name, id or uuid\n    --inactive       show inactive defined XML\n    --security-info  include security sensitive information in XML dump\n    --update-cpu     update guest CPU according to host CPU\n    --migratable     provide XML suitable for migrations\n    \n    \n i think we coudl mvoe nova over to using the uuid to refer to the domain as an inital change early in the serise perhas with a fallback to the name  but i dont think that is require given how long we have been defining the domain with a uuid.\n \n chatgpt says \n```\nimport libvirt\n\nconn \u003d libvirt.open(\"qemu:///system\")\n\nuuid \u003d \"6c90dc6a-72f4-4e19-a482-7f64db74f311\"\n\ntry:\n    domain \u003d conn.lookupByUUIDString(uuid)\n    print(domain.name())\nexcept libvirt.libvirtError:\n    print(\"Domain not found\")\n    ```\n    \nthere is also apprently a bytes version \n    \n    `domain \u003d conn.lookupByUUID(uuid_bytes)`\n    \nbut we are storign the instnace uuid i belive as an actul str not a uuid object so we proably want lookupByUUIDString\n\n\n\nso to wrap this up\n\ni sort of consdier the exsting behvior to be a bug\nwe shoudl be able to look up the domaisn alwasy via the uuid and the config option shoudl jsut be a oeprator prefence\ni agree with updating the default if we can fix the domain lookup\nand i think this shoudl be a prequistie to cross cell live migrate.\n\nwether we track this as part fo the spec or as a separate bug i dont mind too much. its a bug in my view that updatign the config option will break the deployment but its ok to fix it in this large effort too but ideally this woudl be done early so if folks want to backport the lookup fix they could.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":235,"context_line":"for us to effect such a change in our own migration. If that is not possible"},{"line_number":236,"context_line":"for some reason then we may need to simply require operators to hard reboot"},{"line_number":237,"context_line":"their instances before they can be migrated across cells (or accept that the"},{"line_number":238,"context_line":"migration may fail due to a name conflict)."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Alternatives"},{"line_number":241,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e1ee635e_3f93b06c","line":238,"in_reply_to":"3147a9b5_a7d7ed98","updated":"2026-10-01 16:26:15.000000000","message":"I think this needs to be a separate effort.. a migration task people need to handle during upgrade. We\u0027ll figure out the process, what we can do and how live it can be, and make that a separate thing. Note that it\u0027s another benefit of this being a new operation - we can say that v2 requires unique instance names. V1 continues to work until you\u0027ve make it through that hoop, and v2 works in cases where the name doesn\u0027t clash on the destination.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":235,"context_line":"for us to effect such a change in our own migration. If that is not possible"},{"line_number":236,"context_line":"for some reason then we may need to simply require operators to hard reboot"},{"line_number":237,"context_line":"their instances before they can be migrated across cells (or accept that the"},{"line_number":238,"context_line":"migration may fail due to a name conflict)."},{"line_number":239,"context_line":""},{"line_number":240,"context_line":"Alternatives"},{"line_number":241,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9f5cb9bc_eb70a7e3","line":238,"in_reply_to":"e1ee635e_3f93b06c","updated":"2026-10-08 17:23:57.000000000","message":"Acknowledged","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":242,"context_line":""},{"line_number":243,"context_line":"An alternative to the entire approach here is to pass a ``CellMapping`` object"},{"line_number":244,"context_line":"down to the source compute (or conductor) to perform the migration much as it"},{"line_number":245,"context_line":"is today but with the ability to contact the other node directly. Arguments"},{"line_number":246,"context_line":"against this are:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"#. The cell services know nothing about cells today and this would require"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9a7aca1b_8aebebf2","line":245,"updated":"2026-09-30 20:22:09.000000000","message":"im not sure we need to pass the cell mapping down,\n\nwe could be instead we could decompose the current live_migrate rpc call\n\nhttps://docs.openstack.org/nova/2025.1/reference/live-migration.html\n\ntoday the api calls the conductor to start the live migration task, the conductor does rpc calls to the destination and then the sources \n\nhttps://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L307-L324\n\ni think if we are addign a new live migration task\nwe should be orshstating the same flow as we do for cross cell cold migration.\n\nhttps://github.com/openstack/nova/blob/master/nova/conductor/tasks/cross_cell_migrate.py#L842-L853","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":242,"context_line":""},{"line_number":243,"context_line":"An alternative to the entire approach here is to pass a ``CellMapping`` object"},{"line_number":244,"context_line":"down to the source compute (or conductor) to perform the migration much as it"},{"line_number":245,"context_line":"is today but with the ability to contact the other node directly. Arguments"},{"line_number":246,"context_line":"against this are:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"#. The cell services know nothing about cells today and this would require"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a046c72a_0827437f","line":245,"in_reply_to":"9a7aca1b_8aebebf2","updated":"2026-10-01 16:26:15.000000000","message":"The problem is all the calls between the source and destination that the current live migration does. It\u0027s mostly in the cleanup path and the complicated ones are in the failure paths. The systemic problem is that the process is that we assume that we can do all of this at a very fine-grained level between the two nodes and we bury these things deeply. Resize in general has none of that stuff, and it\u0027s definitely not performance-critical like it is in live migration. Cross-cell cold migration has the benefit of not needing to worry about the latency in the middle of the operation.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":242,"context_line":""},{"line_number":243,"context_line":"An alternative to the entire approach here is to pass a ``CellMapping`` object"},{"line_number":244,"context_line":"down to the source compute (or conductor) to perform the migration much as it"},{"line_number":245,"context_line":"is today but with the ability to contact the other node directly. Arguments"},{"line_number":246,"context_line":"against this are:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"#. The cell services know nothing about cells today and this would require"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d34f1db1_ab9d9e0f","line":245,"in_reply_to":"a046c72a_0827437f","updated":"2026-10-08 17:23:57.000000000","message":"No more discussion here and it\u0027s just an alternative so I\u0027ll mark this as resolved.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":246,"context_line":"against this are:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"#. The cell services know nothing about cells today and this would require"},{"line_number":249,"context_line":"   a major change in that area."},{"line_number":250,"context_line":"#. The compute (or conductor) would have to pre-create the instance, which is"},{"line_number":251,"context_line":"   something it does not currently do today. Similarly, they assume they are"},{"line_number":252,"context_line":"   reading the same instance out of the database today, but this scenario would"}],"source_content_type":"text/x-rst","patch_set":1,"id":"eee9e7be_8d31311d","line":249,"updated":"2026-09-30 20:22:09.000000000","message":"yes they woudl need to know what ther elocall cell is but there are pros and cons to that. the compute still dont need to knwo what cell they are in either way.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":246,"context_line":"against this are:"},{"line_number":247,"context_line":""},{"line_number":248,"context_line":"#. The cell services know nothing about cells today and this would require"},{"line_number":249,"context_line":"   a major change in that area."},{"line_number":250,"context_line":"#. The compute (or conductor) would have to pre-create the instance, which is"},{"line_number":251,"context_line":"   something it does not currently do today. Similarly, they assume they are"},{"line_number":252,"context_line":"   reading the same instance out of the database today, but this scenario would"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6f656f3c_9b9d7df0","line":249,"in_reply_to":"eee9e7be_8d31311d","updated":"2026-10-08 17:23:57.000000000","message":"Acknowledged","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"e929e80ab2ebc47a1c76042a2d0900363c47d481","unresolved":false,"context_lines":[{"line_number":248,"context_line":"#. The cell services know nothing about cells today and this would require"},{"line_number":249,"context_line":"   a major change in that area."},{"line_number":250,"context_line":"#. The compute (or conductor) would have to pre-create the instance, which is"},{"line_number":251,"context_line":"   something it does not currently do today. Similarly, they assume they are"},{"line_number":252,"context_line":"   reading the same instance out of the database today, but this scenario would"},{"line_number":253,"context_line":"   have them subtly not doing that."},{"line_number":254,"context_line":"#. Both the source and destination nodes would need to have the ``CellMapping``"}],"source_content_type":"text/x-rst","patch_set":1,"id":"cda30e62_d736f4d2","line":251,"range":{"start_line":251,"start_character":3,"end_line":251,"end_character":44},"updated":"2026-10-05 14:23:55.000000000","message":"because we use Migration records 🙂","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"06c07215266e4e68e1b5d1532f6dd4f192b50c1c","unresolved":false,"context_lines":[{"line_number":248,"context_line":"#. The cell services know nothing about cells today and this would require"},{"line_number":249,"context_line":"   a major change in that area."},{"line_number":250,"context_line":"#. The compute (or conductor) would have to pre-create the instance, which is"},{"line_number":251,"context_line":"   something it does not currently do today. Similarly, they assume they are"},{"line_number":252,"context_line":"   reading the same instance out of the database today, but this scenario would"},{"line_number":253,"context_line":"   have them subtly not doing that."},{"line_number":254,"context_line":"#. Both the source and destination nodes would need to have the ``CellMapping``"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4a60e103_565f3cab","line":251,"range":{"start_line":251,"start_character":3,"end_line":251,"end_character":44},"in_reply_to":"cda30e62_d736f4d2","updated":"2026-10-05 15:41:32.000000000","message":"No, we don\u0027t do that today because you can\u0027t migrate an instance that doesn\u0027t exist in the database.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4ab5206c7314fbd7237f270c8c1f79a1c057eced","unresolved":true,"context_lines":[{"line_number":250,"context_line":"#. The compute (or conductor) would have to pre-create the instance, which is"},{"line_number":251,"context_line":"   something it does not currently do today. Similarly, they assume they are"},{"line_number":252,"context_line":"   reading the same instance out of the database today, but this scenario would"},{"line_number":253,"context_line":"   have them subtly not doing that."},{"line_number":254,"context_line":"#. Both the source and destination nodes would need to have the ``CellMapping``"},{"line_number":255,"context_line":"   for the duration of the operation."},{"line_number":256,"context_line":"#. It would tie the cells together a bit too much for a period of time, both in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"38b4ab80_b366fbe9","line":253,"updated":"2026-09-30 20:22:09.000000000","message":"the conductor would yes, just as it first create the instnace in the target cell deb as the inital step of cross cell cold migration\n\nhttps://github.com/openstack/nova/blob/master/nova/conductor/tasks/cross_cell_migrate.py#L832-L840\n\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/cross-cell-resize.html#super-conductor\n\nthat happens before any checks are done and that feel more corerct to continue doing.\n\n\n```\nTarget DB Setup\n\nBefore we can perform any checks in the destination host, we have to first populate the target cell database with the instance and its related data, e.g. block device mappings, network info cache, instance actions, etc.\n\n```\n\nhttps://github.com/openstack/nova/blob/master/nova/conductor/tasks/cross_cell_migrate.py#L669-L693","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"e5c3728a0b29ce6890ea61f90908d57e3d777faa","unresolved":false,"context_lines":[{"line_number":250,"context_line":"#. The compute (or conductor) would have to pre-create the instance, which is"},{"line_number":251,"context_line":"   something it does not currently do today. Similarly, they assume they are"},{"line_number":252,"context_line":"   reading the same instance out of the database today, but this scenario would"},{"line_number":253,"context_line":"   have them subtly not doing that."},{"line_number":254,"context_line":"#. Both the source and destination nodes would need to have the ``CellMapping``"},{"line_number":255,"context_line":"   for the duration of the operation."},{"line_number":256,"context_line":"#. It would tie the cells together a bit too much for a period of time, both in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b0bce9d9_aebecd1e","line":253,"in_reply_to":"3233f569_067ddd71","updated":"2026-10-08 17:23:57.000000000","message":"I think this is covered by the above discussion about not having a long-running conductor thread required for this work.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b3bf96a3fb9c19fd41636278220dd1ed6071fb39","unresolved":true,"context_lines":[{"line_number":250,"context_line":"#. The compute (or conductor) would have to pre-create the instance, which is"},{"line_number":251,"context_line":"   something it does not currently do today. Similarly, they assume they are"},{"line_number":252,"context_line":"   reading the same instance out of the database today, but this scenario would"},{"line_number":253,"context_line":"   have them subtly not doing that."},{"line_number":254,"context_line":"#. Both the source and destination nodes would need to have the ``CellMapping``"},{"line_number":255,"context_line":"   for the duration of the operation."},{"line_number":256,"context_line":"#. It would tie the cells together a bit too much for a period of time, both in"}],"source_content_type":"text/x-rst","patch_set":1,"id":"3233f569_067ddd71","line":253,"in_reply_to":"38b4ab80_b366fbe9","updated":"2026-10-01 16:26:15.000000000","message":"Again, unless we\u0027re going to tie a long-running and headless conductor thread to the success of this process, we\u0027d need the computes to be able to handle completion. That means the conductor could pre-create the instance but the non-cell-aware nodes will need to clean up the target DB. The current live migration process makes plenty of assumptions of course that they share a single instance object which further complicates bolting this onto the existing process - basically everywhere they have to either handle the case where the instance is shared or not.","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":276,"context_line":"Security impact"},{"line_number":277,"context_line":"---------------"},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"None."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Notifications impact"},{"line_number":282,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5f785f2e_98ae1917","line":279,"updated":"2026-10-08 13:03:22.000000000","message":"I think this is a good place to state that the operation requires libvirt to libvirt connectivity between the cells","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":false,"context_lines":[{"line_number":276,"context_line":"Security impact"},{"line_number":277,"context_line":"---------------"},{"line_number":278,"context_line":""},{"line_number":279,"context_line":"None."},{"line_number":280,"context_line":""},{"line_number":281,"context_line":"Notifications impact"},{"line_number":282,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b31e8b96_e2b8349a","line":279,"in_reply_to":"5f785f2e_98ae1917","updated":"2026-10-08 14:23:45.000000000","message":"Acknowledged","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":false,"context_lines":[{"line_number":342,"context_line":"   happen in a very specific order, and which things can happen"},{"line_number":343,"context_line":"   slowly/later/async. Identify a clear deterministic way that both nodes can"},{"line_number":344,"context_line":"   agree that a migration has succeeded or failed without coordinating"},{"line_number":345,"context_line":"   directly over RPC to avoid cases where they think the other \"won\"."},{"line_number":346,"context_line":"#. Identify re-usable pieces of existing compute node live migration process"},{"line_number":347,"context_line":"   that may need to be split out into separate helpers to facilitate re-use"},{"line_number":348,"context_line":"   between the old and new workflows."}],"source_content_type":"text/x-rst","patch_set":1,"id":"c966fbaa_b92d07b1","line":345,"updated":"2026-10-08 13:03:22.000000000","message":"femtonit: maybe add: see also edge case gathering strategy in the testing section","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"982386400fcf6031f20de91b12f2182eb79126c1","unresolved":true,"context_lines":[{"line_number":366,"context_line":"for test coverage of the new flow. In-tree tests for bugs and regressions that"},{"line_number":367,"context_line":"have been fixed over the years as well as edge cases and complex failure modes"},{"line_number":368,"context_line":"(and the resulting cleanup) will need to be examined carefully. Some of the"},{"line_number":369,"context_line":"existing tests will cover cases no possible with the new flow, but many of the"},{"line_number":370,"context_line":"situations and scenarios will apply, even if they must be tested in a different"},{"line_number":371,"context_line":"way."},{"line_number":372,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"e6731887_205988bc","line":369,"range":{"start_line":369,"start_character":14,"end_line":369,"end_character":43},"updated":"2026-10-08 13:03:22.000000000","message":"nit: no -\u003e not","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"7d1c4a4e93e0142429c14d26d32648bbcffb987a","unresolved":false,"context_lines":[{"line_number":366,"context_line":"for test coverage of the new flow. In-tree tests for bugs and regressions that"},{"line_number":367,"context_line":"have been fixed over the years as well as edge cases and complex failure modes"},{"line_number":368,"context_line":"(and the resulting cleanup) will need to be examined carefully. Some of the"},{"line_number":369,"context_line":"existing tests will cover cases no possible with the new flow, but many of the"},{"line_number":370,"context_line":"situations and scenarios will apply, even if they must be tested in a different"},{"line_number":371,"context_line":"way."},{"line_number":372,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"80bc57db_a05797f9","line":369,"range":{"start_line":369,"start_character":14,"end_line":369,"end_character":43},"in_reply_to":"e6731887_205988bc","updated":"2026-10-08 14:23:45.000000000","message":"Acknowledged","commit_id":"5bcfe9d036bfb35070dc0d2d219fb9ca0458c703"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":true,"context_lines":[{"line_number":61,"context_line":"This spec proposes a new API operation (called `os-migrateLiveV2` for the"},{"line_number":62,"context_line":"moment), a new conductor task, and new compute RPC plumbing that implement the"},{"line_number":63,"context_line":"above goals. Much of the internals will be re-used but with new RPC calls that"},{"line_number":64,"context_line":"carry different pre/post condition expectations. This new operation will be"},{"line_number":65,"context_line":"an eventual replacement for the current live migration operation, not simply"},{"line_number":66,"context_line":"an alternative when cross-cell behaviors are desired."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The new process will be implemented in conductor as a new task class, peer to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"c6055f47_e4f697bb","line":65,"range":{"start_line":64,"start_character":49,"end_line":65,"end_character":64},"updated":"2026-10-09 08:29:36.000000000","message":"I\u0027m fine with this wording, which clearly states that we will eventually deprecate the legacy API endpoint. Let\u0027s defer at implementation stage how we communicate it (one open thought is that it could be reflected on the API docs at least)","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":63,"context_line":"above goals. Much of the internals will be re-used but with new RPC calls that"},{"line_number":64,"context_line":"carry different pre/post condition expectations. This new operation will be"},{"line_number":65,"context_line":"an eventual replacement for the current live migration operation, not simply"},{"line_number":66,"context_line":"an alternative when cross-cell behaviors are desired."},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"The new process will be implemented in conductor as a new task class, peer to"},{"line_number":69,"context_line":"the existing ``LiveMigrateTask``, but modeled after the cross-cell cold"}],"source_content_type":"text/x-rst","patch_set":2,"id":"47f1124d_23b2f177","line":66,"updated":"2026-10-08 19:45:22.000000000","message":"i do not think this should be a new api this i think is one of the larger directional issue with this propsoal.\n\ni will reserve judgment till i have read this in more detail on this new revision but i do nto belive this is correct form the api sig point of view or cosnitent with how we have been evolving the API for year.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":false,"context_lines":[{"line_number":75,"context_line":"decide to treat it like virt/network driver removals in the past, or we could"},{"line_number":76,"context_line":"consider hooking up the v2 plumbing in a way that allows \"as compatible as"},{"line_number":77,"context_line":"possible\" behavior to be honored through the old API. That decision can be"},{"line_number":78,"context_line":"deferred to that point."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"New API operation"},{"line_number":81,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"aff78aac_ff68d75b","line":78,"updated":"2026-10-09 08:29:36.000000000","message":"+100","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"bec32e82e810faa7e420b0227afd0df94e20ca7d","unresolved":false,"context_lines":[{"line_number":75,"context_line":"decide to treat it like virt/network driver removals in the past, or we could"},{"line_number":76,"context_line":"consider hooking up the v2 plumbing in a way that allows \"as compatible as"},{"line_number":77,"context_line":"possible\" behavior to be honored through the old API. That decision can be"},{"line_number":78,"context_line":"deferred to that point."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"New API operation"},{"line_number":81,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"be937875_eb7989c5","line":78,"in_reply_to":"aff78aac_ff68d75b","updated":"2026-10-13 19:16:27.000000000","message":"yeah, there are many possible way to handle the old migration API/code but that we can decide later and does not need to have a concrete agreement as part of this spec.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":87,"context_line":"leave the existing flow alone."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Benefits:"},{"line_number":90,"context_line":" - Avoids disturbing the existing live migration code and allows it to remain a"},{"line_number":91,"context_line":"   viable alternative until the new operation is trusted"},{"line_number":92,"context_line":" - Avoids needing to maintain compatibility with the existing flow, further"},{"line_number":93,"context_line":"   complicating the existing code and allowing the new code to rethink some"},{"line_number":94,"context_line":"   things."},{"line_number":95,"context_line":" - Provides us a path to ultimately deprecate and \"remove\" the old mechanism"},{"line_number":96,"context_line":"   (like we have done when dropping virt drivers, network models, etc)"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"dd409ab7_ed59ef4c","line":94,"range":{"start_line":90,"start_character":0,"end_line":94,"end_character":10},"updated":"2026-10-08 19:45:22.000000000","message":"i disagree with this because we coudl just fail the live migration in the conductor if it use a parameter form an older api that we dont support in this flow.\n\nwe can simpley determin if the migration is cross cell or not in teh conducto live migtation task  after we select the detionon and chosoe the correct internal path based on that.\n\nlitally here\n\nhttps://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L82-L132\n\n\nif you are specifying an az you dont know if its cross cell until after that point anyway since AZ can span cell bondaries by desing\n\ntechnially if you specify a host you could check the cell mapping earler but in the genral case where you eihter allowt the schduler to choose ro use an az you cant determin if its coss ceel until that point.\n\nand at that point we are just starting our intiall precheck.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3d98c5b2e635f78cef40c813b9a7037032ab6e73","unresolved":true,"context_lines":[{"line_number":87,"context_line":"leave the existing flow alone."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Benefits:"},{"line_number":90,"context_line":" - Avoids disturbing the existing live migration code and allows it to remain a"},{"line_number":91,"context_line":"   viable alternative until the new operation is trusted"},{"line_number":92,"context_line":" - Avoids needing to maintain compatibility with the existing flow, further"},{"line_number":93,"context_line":"   complicating the existing code and allowing the new code to rethink some"},{"line_number":94,"context_line":"   things."},{"line_number":95,"context_line":" - Provides us a path to ultimately deprecate and \"remove\" the old mechanism"},{"line_number":96,"context_line":"   (like we have done when dropping virt drivers, network models, etc)"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"f3df68ae_efe381ee","line":94,"range":{"start_line":90,"start_character":0,"end_line":94,"end_character":10},"in_reply_to":"dd409ab7_ed59ef4c","updated":"2026-10-08 20:27:01.000000000","message":"\u003e i disagree with this because we coudl just fail the live migration in the conductor if it use a parameter form an older api that we dont support in this flow.\n\nIt seems like you argue below that creating a new API is sidestepping the versioning guidelines (which it totally is, but very much in line with many other such decisions we\u0027ve made). However, here it seems like you\u0027re saying we\u0027d just refuse to do the migration if the user is trying to live migrate at 2.1, which we can\u0027t do with this new plumbing. That\u0027s just refusing earlier microversions for an API that hasn\u0027t been entirely deprecated, which is a much worse sin to me. Am I missing something about what you\u0027re proposing?\n\n\u003e we can simpley determin if the migration is cross cell or not in teh conducto live migtation task  after we select the detionon and chosoe the correct internal path based on that.\n\nI\u0027m not sure if you are arguing for having a parallel path only for cross-cell live migrations or if you\u0027ve missed the responses earlier. The goal is to have a single new live migration flow that is basically the same regardless if if we\u0027re crossing a cell boundary or not (and which can clean up some very nasty warts in the current design regardless of cell). Obviously if we are crossing cells we need to pre-create the new instance record and delete the old one, but otherwise I want the flow to be the same. When you say \"we can determine if the migration is cross-cell or not and choose the correct internal path\" it makes me think you actually want separate paths for those things. I very much do not.\n\n\u003e if you are specifying an az you dont know if its cross cell until after that point anyway since AZ can span cell bondaries by desing\n\nAgree, but again, we don\u0027t need to make an \"is this cross cell\" determination for any of the plumbing if the plumbing all works the same way regardless of if we\u0027re crossing cells or not.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e369c28dc67fb23b486b822df2be859ed364c0f6","unresolved":true,"context_lines":[{"line_number":87,"context_line":"leave the existing flow alone."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Benefits:"},{"line_number":90,"context_line":" - Avoids disturbing the existing live migration code and allows it to remain a"},{"line_number":91,"context_line":"   viable alternative until the new operation is trusted"},{"line_number":92,"context_line":" - Avoids needing to maintain compatibility with the existing flow, further"},{"line_number":93,"context_line":"   complicating the existing code and allowing the new code to rethink some"},{"line_number":94,"context_line":"   things."},{"line_number":95,"context_line":" - Provides us a path to ultimately deprecate and \"remove\" the old mechanism"},{"line_number":96,"context_line":"   (like we have done when dropping virt drivers, network models, etc)"},{"line_number":97,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"ac086bb0_4129c498","line":94,"range":{"start_line":90,"start_character":0,"end_line":94,"end_character":10},"in_reply_to":"f3df68ae_efe381ee","updated":"2026-10-09 15:27:31.000000000","message":"putting the dest az aside for a seocnd since i think that should be its own microverison implmented in the existing live migration path beofre any of this other work my prefence is basically as follows\n\nin this spec you defien the effeictve micro version/supproted parmater ~2.34 currently \n\nin the api we do not do any additonal validation or api semantic chagne.\n\nin the conductor task at the start of execute we determin 2 thing\n\nfrist we calulate a flag (allows_cross_cell) by looking at the input parmaters (block_migration, disk_over_commit ectra) second \n\nwe modify \n\nhttps://github.com/openstack/nova/blob/c77d53959071b5c06a4c2cbaa6b7fcd0b80906c0/nova/conductor/tasks/live_migrate.py#L95-L111\n\nto pass  allows_corss_cell to self._find_destination() and and an expclt\ncheck when a dest host is provided that either cross cell is not allowed that the dest is in the same cell.\n\n\nif the request disallows cross cell i.e by passing block_migration\u003dtrue\nand the destination is in a diffetn cell we faile the migtration us as if  it fialed the self._check_host_is_up(self.destination) check today\nreporting a exiplcty error in the migrtion result stating that the designation host is not allowed based ont eh request parameters or simialr.\n\nwe dont have to say its because its in a different cell but we could if we want to be more explcit so that admins knwo what the issue is.\n\nwe can even recommend trying again without the relevng flag i.e droping \n--block_migration\u003dtrue if we wanted in the message that not the imporant part.\n\nthe impatn par ti swe are failing the migration if and only if the destiation and souce are not valid for that request based on the other input.\n\nif they were in the same cell it word work\n\nthis is no diffent then hte failrue more we woudl have if the vm is pinned to AZ1 and you asked ot move ti to AZ2.\n\n\nso the useage of the new live mgiration code path woudl be gated by the internally caludated allows_cross_cell\n\nthat v2 code path can use an entirly seprate set of rpc methods so that we do not have to disturbe any fo the exsting test or live mgiratoin code path at the compute rpc level.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":93,"context_line":"   complicating the existing code and allowing the new code to rethink some"},{"line_number":94,"context_line":"   things."},{"line_number":95,"context_line":" - Provides us a path to ultimately deprecate and \"remove\" the old mechanism"},{"line_number":96,"context_line":"   (like we have done when dropping virt drivers, network models, etc)"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Drawbacks:"},{"line_number":99,"context_line":" - Adds a new API, requiries some handling in the client, users will need to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"017a0df1_171b11b0","line":96,"updated":"2026-10-08 19:45:22.000000000","message":"that already exist by raising or min microverson\n\ncreate a v2 api is just side steping the actull correct way to do that.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3d98c5b2e635f78cef40c813b9a7037032ab6e73","unresolved":true,"context_lines":[{"line_number":93,"context_line":"   complicating the existing code and allowing the new code to rethink some"},{"line_number":94,"context_line":"   things."},{"line_number":95,"context_line":" - Provides us a path to ultimately deprecate and \"remove\" the old mechanism"},{"line_number":96,"context_line":"   (like we have done when dropping virt drivers, network models, etc)"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Drawbacks:"},{"line_number":99,"context_line":" - Adds a new API, requiries some handling in the client, users will need to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bdb0dbfc_3ee8bbea","line":96,"in_reply_to":"017a0df1_171b11b0","updated":"2026-10-08 20:27:01.000000000","message":"It is, but we\u0027ve made plenty of practical decisions to remove things like hypervisor-specific APIs, the network stuff, etc though this mechanism. I think the most pertinent example is when Stephen removed a server action, peer to this one:\n\nhttps://review.opendev.org/c/openstack/nova/+/749315\n\nWe could have supported that forever, we could have said we can\u0027t remove it until we raise the minimum version. However, the greater good was to remove the thing without causing all the other havoc that would come with keeping or bumping.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Drawbacks:"},{"line_number":99,"context_line":" - Adds a new API, requiries some handling in the client, users will need to"},{"line_number":100,"context_line":"   know the differences"},{"line_number":101,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":102,"context_line":"   remove more in the long run)"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"95931a39_3723c4db","line":100,"updated":"2026-10-08 19:45:22.000000000","message":"how woudl a clinet know which one to use.\n\nif it requries any knowlove of which cell the vm is in and where or not the destiation is in a diffent cell i dont think that is ok.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3d98c5b2e635f78cef40c813b9a7037032ab6e73","unresolved":true,"context_lines":[{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Drawbacks:"},{"line_number":99,"context_line":" - Adds a new API, requiries some handling in the client, users will need to"},{"line_number":100,"context_line":"   know the differences"},{"line_number":101,"context_line":" - Duplicated code for some time to come (although ultimately an opportunity to"},{"line_number":102,"context_line":"   remove more in the long run)"},{"line_number":103,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"2448a152_3f0578ee","line":100,"in_reply_to":"95931a39_3723c4db","updated":"2026-10-08 20:27:01.000000000","message":"The same way they know to use a particular microversion to get specific features today I guess. They\u0027d see \"the old thing is going away, I had better start using v2 whenever I can and reporting bugs with it before v1 is dropped\".","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":false,"context_lines":[{"line_number":122,"context_line":"instance has moved, which could incorrectly constrain scheduling for later"},{"line_number":123,"context_line":"operations such as resize or evacuation. Note that choosing a destination host"},{"line_number":124,"context_line":"outside the currently-pinned AZ will also result in scheduling failure, as it"},{"line_number":125,"context_line":"does with live migration today."},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"An additional policy rule will be added to control whether or not a user is"},{"line_number":128,"context_line":"allowed to push a migration across cell boundaries. This will mirror the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"04af4545_d987fa01","line":125,"updated":"2026-10-09 08:29:36.000000000","message":"++","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":false,"context_lines":[{"line_number":129,"context_line":"`compute:servers:resize:cross_cell` policy knob we have for cold migration."},{"line_number":130,"context_line":"Since live migration (unlike cold migration and resize) is an admin-only"},{"line_number":131,"context_line":"operation, this extra knob will initialy default to the same value as for"},{"line_number":132,"context_line":"live migration itself (i.e. admin only)."},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"Ownership of the process"},{"line_number":135,"context_line":"------------------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"effc2cec_bfcda0e4","line":132,"updated":"2026-10-09 08:29:36.000000000","message":"good idea","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":145,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":146,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"},{"line_number":147,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":148,"context_line":"then will kick off the actual migration with the source node."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":151,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d91aa5f6_256e1847","line":148,"updated":"2026-10-08 19:45:22.000000000","message":"this kind of demisihsies what that actully involes\n\nit need to do more then that it need to do the pci,numa, and other device cleaims in cludign creating the destation host neutron port bidning.\n\nand retrun the migratde_data obejct so that we can pass that to the souce host\nso it can generate the destiantion xml by modifyign the souce xml\n\nim not sayign that is hard but we will need pre_live_migratoin_at_conductor\n\nto call the souce host to gerenate the partially populated live migration data obejct, return that to the conductor so it can then call the dest with that so it can finsih populsateing it and then thread that through to the final live migrate call to the souce node wiht any other info the conductor has prepared.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e7233113f02289940e8b2ba01921b1dc939522d7","unresolved":false,"context_lines":[{"line_number":145,"context_line":"database and setting up the cell routing for the new instance (more on that"},{"line_number":146,"context_line":"later). It will perform the equivalent of the \"pre_live_migration\" operation"},{"line_number":147,"context_line":"today, which informs the receiving compute node of the pending operation and"},{"line_number":148,"context_line":"then will kick off the actual migration with the source node."},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"For a cross-cell migration, the conductor will create the destination instance"},{"line_number":151,"context_line":"with ``hidden`` set, together with the instance\u0027s block device mappings,"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d1e0ffad_84a5502c","line":148,"in_reply_to":"d91aa5f6_256e1847","updated":"2026-10-21 14:35:22.000000000","message":"Acknowledged","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":true,"context_lines":[{"line_number":154,"context_line":"confirmed the migration completed. If the migration is rolled back, the"},{"line_number":155,"context_line":"destination records will be hard-deleted."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"It should be noted that an important aspect of the design here is that the"},{"line_number":158,"context_line":"conductor task thread does not persist through the duration of the migration"},{"line_number":159,"context_line":"operation. A naive approach with such a long-running task seems advantageous,"},{"line_number":160,"context_line":"in that the conductor retains the ability to perform cross-cell cleanup (in"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5a6bc93c_b9b064d0","line":157,"range":{"start_line":157,"start_character":23,"end_line":157,"end_character":62},"updated":"2026-10-09 08:29:36.000000000","message":"another aspect of the current design proposal is that we reuse most of the existing RPC calls, we just reorder the workflows, leading us to some implementation constraints, one being the fact that we require to mirror the instance record in the destination cell DB before the migration starts.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":168,"context_line":"compromise the operation. Thus, the proposal here does not increase the number"},{"line_number":169,"context_line":"and scope of nodes that are involved in the critical part of operation, it"},{"line_number":170,"context_line":"simply rebalances the responsibilities and expectations between the"},{"line_number":171,"context_line":"source and destination."},{"line_number":172,"context_line":""},{"line_number":173,"context_line":"The destination compute node will take a more active role in the migration in"},{"line_number":174,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a95961d_25488c48","line":171,"updated":"2026-10-08 19:45:22.000000000","message":"im still not entirly convice by this.\ni understand the concer with the long runign thread adn adding a third element that must survive till the end.\n\n\nbut i still think it would likely be better to have 2 new conductor rpc api that the souce/dest host could call to signal soccues/failure and or move to the next pahse.\n\nthat can be entirly stateles form the perspective of inmemory state, just an rpc cast form the souce to the conductor to signal the need for rolback or post live migration phase.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":174,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"},{"line_number":175,"context_line":"it to expect an incoming migration. Today we already \"record\" that a task is"},{"line_number":176,"context_line":"started so that we can avoid shutting down until a pending migration has"},{"line_number":177,"context_line":"completed. In the new flow this will start an actual thread that will monitor"},{"line_number":178,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":179,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":180,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":181,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":182,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ac2f136_31bd5f04","line":179,"range":{"start_line":177,"start_character":11,"end_line":179,"end_character":11},"updated":"2026-10-08 19:45:22.000000000","message":"this feels liek we are using libvirt task api as a rpc mechnaium and or using the virt lifecycle event form the vm to triger operations.\n\nhow does this work for the vmware or zvm virt drivers?\n\nthis new approach should at least be implementable by any virt driver capable of live migration.\n\nand in fact the coordination here should be implemented in mostly at the driver independent compute manager and conductor task level.\n\nso im not sure how tracking the placement allctions or present of the matich vm is really going to be enouch without chaging the virt driver api.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"b460bd922e6c2320eda27d7b82809fdfb79267e9","unresolved":true,"context_lines":[{"line_number":174,"context_line":"the new flow, by starting an actual monitor thread when the conductor informs"},{"line_number":175,"context_line":"it to expect an incoming migration. Today we already \"record\" that a task is"},{"line_number":176,"context_line":"started so that we can avoid shutting down until a pending migration has"},{"line_number":177,"context_line":"completed. In the new flow this will start an actual thread that will monitor"},{"line_number":178,"context_line":"for the incoming migrated virtual machine, and finish the process once it is"},{"line_number":179,"context_line":"completed. It will be able to monitor global information like placement"},{"line_number":180,"context_line":"allocations, as well as local information such as the presence of a matching"},{"line_number":181,"context_line":"libvirt virtual machine. It will also need to determine when a migration has"},{"line_number":182,"context_line":"been aborted and do cleanup. It may determine a migration has failed because"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a2ee866e_28bbd66c","line":179,"range":{"start_line":177,"start_character":11,"end_line":179,"end_character":11},"in_reply_to":"3ac2f136_31bd5f04","updated":"2026-10-14 13:00:33.000000000","message":"This is an interesting aspect. I\u0027m not an expert but given the simplicity of the live migration support in the vmware driver[1]. I\u0027m not really worried about support for the new semantics there later. But we can ask @fabian.wiesel@sap.com to chime in. \n\n[1] https://github.com/openstack/nova/blob/168d437a4dc93377853ddf71431100d424c9958b/nova/virt/vmwareapi/driver.py#L290-L313\n\n---\n\nThe zvm case even simpler. That driver does not support live-migration today. Also I don\u0027t think we have anybody active in the community maintaining it so I think we can ignore this driver for the discussion. (And maybe stat another one about deprecating that driver)","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":185,"context_line":"has been determined will be done, and the source node will (as described below)"},{"line_number":186,"context_line":"handle global resource revert/cleanup. Initially we will consider the placement"},{"line_number":187,"context_line":"allocation confirm/revert to be the definitive trigger for success/failure"},{"line_number":188,"context_line":"as viewed by the destination node."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"The source compute node will be responsible for starting the migration, doing"},{"line_number":191,"context_line":"the time-sensitive task of activating the port bindings for the destination"}],"source_content_type":"text/x-rst","patch_set":2,"id":"fb17a2f7_21e90ac3","line":188,"updated":"2026-10-08 19:45:22.000000000","message":"this feels like an abuse of placement to me\n\nthe allocations are the atomic sideffect of allcoating resouce to a vm on a given host but the athroitve souce of host the vm is on is the nova db and the instace.host filed not the placement allcoations.\n\nbased on my recolection today we hold the souce allocations to the migration uuid  \nand  then we create the destination allocation in placment beofre we start the live migration with the instance uuid after scheduling\n\ni asked ai to create secquence diagrams fo the flow\n\nhttps://gist.github.com/SeanMooney/23047dd07b36877836f67c60b1a9470d\n\nthe imporant part is \n\nhttps://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L86-L93\n\nthis is before we have even schdueld or validated if the desination is valid\n\nhttps://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L95-L111\n\n\nso you would actully be monitoring the removal of the allocation held by the migration uuid for confirm and the deleting of the instance allcoation agentst the destiation for reviert.\n\nthis feels fragile to me.\n\nwhat happens if a opertor deletes the migration allcotions in placemnet early and tries to rebuild them with nova-manage heal allcoations.\n\ni have been on enouch custoemr supprot ticket to know that its not uncommon for custoemr or supprot folks to do that because the read an old debuging articl that said to do that.\n\nif we are pooling anyting it shoudl be the migration object or somehting in nova db that is not externally modifyable like the placement allcoation.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6f2885410f23dd57435224c86d4243dab9df10db","unresolved":false,"context_lines":[{"line_number":185,"context_line":"has been determined will be done, and the source node will (as described below)"},{"line_number":186,"context_line":"handle global resource revert/cleanup. Initially we will consider the placement"},{"line_number":187,"context_line":"allocation confirm/revert to be the definitive trigger for success/failure"},{"line_number":188,"context_line":"as viewed by the destination node."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"The source compute node will be responsible for starting the migration, doing"},{"line_number":191,"context_line":"the time-sensitive task of activating the port bindings for the destination"}],"source_content_type":"text/x-rst","patch_set":2,"id":"f8705079_27c6457f","line":188,"in_reply_to":"dd908825_b5f8ad49","updated":"2026-10-15 19:23:47.000000000","message":"Per the PTG discussion I\u0027m adding words about using consumer_type","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"b460bd922e6c2320eda27d7b82809fdfb79267e9","unresolved":true,"context_lines":[{"line_number":185,"context_line":"has been determined will be done, and the source node will (as described below)"},{"line_number":186,"context_line":"handle global resource revert/cleanup. Initially we will consider the placement"},{"line_number":187,"context_line":"allocation confirm/revert to be the definitive trigger for success/failure"},{"line_number":188,"context_line":"as viewed by the destination node."},{"line_number":189,"context_line":""},{"line_number":190,"context_line":"The source compute node will be responsible for starting the migration, doing"},{"line_number":191,"context_line":"the time-sensitive task of activating the port bindings for the destination"}],"source_content_type":"text/x-rst","patch_set":2,"id":"dd908825_b5f8ad49","line":188,"in_reply_to":"fb17a2f7_21e90ac3","updated":"2026-10-14 13:00:33.000000000","message":"\u003e so you would actully be monitoring the removal of the allocation held by the migration uuid for confirm and the deleting of the instance allcoation agentst the destiation for reviert.\n\nIf a compute only looks at its on RP tree in placement (and associated things like sharing providers, allocations etc) that seems to be OK to me. That data exactly about that given compute. We already partially do that in some of our periodic tasks in the compute to detect orphans. e.g. https://github.com/openstack/nova/blob/168d437a4dc93377853ddf71431100d424c9958b/nova/compute/resource_tracker.py#L1840\n\n\u003e this is before we have even schdueld or validated if the desination is valid\n\nyeah but that will only affect the source compute as the allocation that is moved from instance_uuid to migration_uuid is the source compute allocation. So the dest compute will not react to it. (also at this point the migration record might not even exists in the dest cell to create any kind of trigger on the dest side about this migration)\n\n\n\u003e what happens if a opertor deletes the migration allcotions in placemnet early and tries to rebuild them with nova-manage heal allcoations.\n\n\u003e i have been on enouch custoemr supprot ticket to know that its not uncommon for custoemr or supprot folks to do that because the read an old debuging articl that said to do that.\n\n\u003e if we are pooling anyting it shoudl be the migration object or somehting in nova db that is not externally modifyable like the placement allcoation.\n\nI think the compute will / should only care about allocations appearing / disappearing where it can pair it with a migration record.\n\nAlso if the customer have a running live migration and deletes the allocations in Placement and the migration finishes, it will create a failure that a simple heal allocation might not able to fix. So this is not a new thing. We assume that the data nova puts into placement is not deleted by others. Similarly how if nova puts a port binding into neutron nova expects that the binding (and the port) is not deleted by an admin. (We run with just this assumption successfully for many many years before Neutron finally added a check for it enforce it recently https://review.opendev.org/c/openstack/neutron/+/1002490 )","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":255,"context_line":"within the cell they are in by default, unless directed by an availability"},{"line_number":256,"context_line":"zone or host instruction. Thus I would propose a weigher that by default"},{"line_number":257,"context_line":"scores same-cell hosts much higher than others (I have not yet looked into if"},{"line_number":258,"context_line":"or how this will be implemented). Another option would be to only choose hosts"},{"line_number":259,"context_line":"in the same cell _unless_ an AZ or destination host are provided, although"},{"line_number":260,"context_line":"that will be more obscure and less transparent. Thus I think the options are:"},{"line_number":261,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"f3a5a606_4d5d808d","line":258,"updated":"2026-10-08 19:45:22.000000000","message":"this already exists \nhttps://github.com/openstack/nova/blob/master/nova/scheduler/weights/cross_cell.py\nit was intorduced with cross cell cold migration\n\nthe default multipler is `1000000.0` so unless you have 1 host in the souce cel, have disabeld large portion of our hosts or are at very close to capsitcy the scduelr will almsot never select a host in a diffent cell unless forced to by some kind of hint like an az or host in the request.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6f2885410f23dd57435224c86d4243dab9df10db","unresolved":false,"context_lines":[{"line_number":255,"context_line":"within the cell they are in by default, unless directed by an availability"},{"line_number":256,"context_line":"zone or host instruction. Thus I would propose a weigher that by default"},{"line_number":257,"context_line":"scores same-cell hosts much higher than others (I have not yet looked into if"},{"line_number":258,"context_line":"or how this will be implemented). Another option would be to only choose hosts"},{"line_number":259,"context_line":"in the same cell _unless_ an AZ or destination host are provided, although"},{"line_number":260,"context_line":"that will be more obscure and less transparent. Thus I think the options are:"},{"line_number":261,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"43870bcf_6c7896b9","line":258,"in_reply_to":"f3a5a606_4d5d808d","updated":"2026-10-15 19:23:47.000000000","message":"Done","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":260,"context_line":"that will be more obscure and less transparent. Thus I think the options are:"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"1. No preference, cluster-wide scheduling always"},{"line_number":263,"context_line":"2. Weigh same-cell hosts higher by default"},{"line_number":264,"context_line":"3. Restrict to same-cell hosts unless an AZ or host is provided"},{"line_number":265,"context_line":"4. Some other direction like a flag"},{"line_number":266,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"8929c14c_fa388928","line":263,"updated":"2026-10-08 19:45:22.000000000","message":"2 is effectivly what we have today\n\ni also think that is the correct option","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6f2885410f23dd57435224c86d4243dab9df10db","unresolved":false,"context_lines":[{"line_number":260,"context_line":"that will be more obscure and less transparent. Thus I think the options are:"},{"line_number":261,"context_line":""},{"line_number":262,"context_line":"1. No preference, cluster-wide scheduling always"},{"line_number":263,"context_line":"2. Weigh same-cell hosts higher by default"},{"line_number":264,"context_line":"3. Restrict to same-cell hosts unless an AZ or host is provided"},{"line_number":265,"context_line":"4. Some other direction like a flag"},{"line_number":266,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"1006338c_2b494417","line":263,"in_reply_to":"8929c14c_fa388928","updated":"2026-10-15 19:23:47.000000000","message":"Done","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8caa2b25324ee505f8f7d777ded08c1adccb6056","unresolved":true,"context_lines":[{"line_number":295,"context_line":""},{"line_number":296,"context_line":"For now, we will document that in order for this to work, you must have"},{"line_number":297,"context_line":"changed your instance name template to something database-independent. We will"},{"line_number":298,"context_line":"handle migration of the default separately to this effort."},{"line_number":299,"context_line":""},{"line_number":300,"context_line":"Alternatives"},{"line_number":301,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"830595fa_969fff55","line":298,"updated":"2026-10-08 19:45:22.000000000","message":"i know we cant change this within a cell once isntance are defiend today we could fix that but that a seperate pont then the one i want to make.\n\nthis can vary across cell and because of how cross cell cold migratno/resize works today you can cold migrate between cells with diffent config.\n\nbut if its set to diffent values on diffent cells it likely woudl not break on live migrat but worse succeed and then the instance woudl break on hard reboot.\n\nso i agree with the docuemtion but i think this need to be part of the conductre cross cell pre migration checks.\n\nwe need to bail early if the twohost disagree unless we do something like recored the instance-name value in the instance system metadata table so we have a way to recored what it wasand do migraitons of this propelry. i think stpehn mention he had a patch to do somthing like that in the past but i dont know how complete it was. i could not find it in gerrit to check.","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"a32b7de844096bbecbe4c81b55e91199f79c51df","unresolved":false,"context_lines":[{"line_number":321,"context_line":"Another alternative would be to create an upcall relationship between conmpute"},{"line_number":322,"context_line":"and superconductor (or cell and super conductors). This would be extremely"},{"line_number":323,"context_line":"unfortunate and would basically cause every real deployment to have upcalls"},{"line_number":324,"context_line":"enabled forever going forward. But it is technically an option."},{"line_number":325,"context_line":""},{"line_number":326,"context_line":"Data model impact"},{"line_number":327,"context_line":"-----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5f43ad56_3121b561","line":324,"updated":"2026-10-09 08:29:36.000000000","message":"++","commit_id":"d6a41dac53ece958a1aef5db8e7a430a50f70826"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6080756f46e9a1f5f51b3c55a2d62852ae4690b7","unresolved":true,"context_lines":[{"line_number":8,"context_line":"Cross-Cell Live Migration"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cross-cell-live-migration"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Cells have been a native part of Nova for years now, yet live migration between"},{"line_number":14,"context_line":"cells is still not implemented. In order to allow for more adoption of multiple"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ce194d35_02a8d99d","line":11,"updated":"2026-10-20 14:20:45.000000000","message":"this is still 404 for me, I think it is time to file the bp","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9e7e7e1e1c99930fe04c39d4e80f07191e0e8b39","unresolved":false,"context_lines":[{"line_number":8,"context_line":"Cross-Cell Live Migration"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"https://blueprints.launchpad.net/nova/+spec/cross-cell-live-migration"},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Cells have been a native part of Nova for years now, yet live migration between"},{"line_number":14,"context_line":"cells is still not implemented. In order to allow for more adoption of multiple"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0bb24ad5_cb006b9d","line":11,"in_reply_to":"ce194d35_02a8d99d","updated":"2026-10-20 14:28:57.000000000","message":"200 now :)","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"68fcc256d771013fd65c4ac2d3e1123475607705","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"abf8947f_c922b43c","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"updated":"2026-10-21 01:31:32.000000000","message":"I know this is a limitation in v1, and the admin needs to do two operations for pinned instances (unpin AZ and then live migrate), but it would be good if we could make it a single operation in the v2 API. I\u0027m just curious: if it\u0027s not Compute, can we unpin it (update request spec) at the API level and then let Compute do the live migration as per the \u0027dest_availability_zone\u0027? If migration fails, then rollback can unpin the AZ and can revert the request spec to the old AZ via super conductor)?","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"b727faa7ae18022d0a927f4c18bb0c1287e5a5ad","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"93ce6181_dca09701","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"0522f768_80f5ced4","updated":"2026-10-28 14:24:50.000000000","message":"\u003e \u003e im not ok with adding AZ to live migration without adding it to cold migrate in the same microverions.\n\u003e \n\u003e Sorry this will not fly for me. If we cannot do iterative development and limit the scope of the spec then I\u0027m pretty sure this will not be done at all as we will simply alienate our developer base by asking too much from them. Why we need everything in a single step? Is this some kind of gatekeeping?\n\nYeah, these seem like separate (if related) efforts. API microversions allow us to tackle this separately.\n\nI do still think the `dest_` prefix is superfluous though (I\u0027ve discussed that with Dan already in another thread).","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d49e9698e8b25cc5e401c999091d52eff4b80263","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3250b56d_6f56e693","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"149bfcdc_eacae307","updated":"2026-10-21 15:11:38.000000000","message":"\u003e well the migration object already has the old/new host and flavor right\n\u003e \n\u003e https://github.com/openstack/nova/blob/master/nova/objects/migration.py#L67-L77\n\u003e \n\u003e and a flag for if its a corss cell move\n\u003e https://github.com/openstack/nova/blob/master/nova/objects/migration.py#L88\n\nTo me the migration object is the wrong place for this to be. We need to be able to service partial instance requests from the ReqSpec if the cell is down and the existing pin is stored there. So I think this needs to be there for symmetry (just like the old_cell_id).\n\n\u003e so we can jsut add the old and new az\n\nNot just AZ, but the desired pinning. Presumably we need to support at least pinned-\u003epinned and unpinned-\u003epinned. The problem with assuming `dest_availability_zone` means \"...and pin me there\" is that most of the operators I\u0027ve heard that want to use this purely want it for convenience of moving to a different area without having to do their own host picking. We could pin to the target AZ if you were pinned before, but I\u0027m not sure that\u0027s always what people would want.\n\n\u003e and as part of finalisation of the cell mapping on failure we can restore the preior az value if there was a pin.\n\u003e \n\u003e the migration object need to exist in both cells so we can read this back even if we have deleted the entries on the destiaion already asyconosly.\n\u003e \n\u003e for me this shoudl be part of adding the AZ parmater so if you want to spelit that i think it woudl be ok but i woudl prefer not to punt this if we intennd to add the AZ parmater to the action.\n\nAs above, I think that the existing naming of `dest_availability_zone` as a \"scope your scheduling to hosts in this zone\" makes plenty of sense without pinning you there and is very much something people want just to make the act of slide-puzzle-upgrade or evacuate-the-burning-rack workflows easier. It\u0027s also weird (to me) to have AZ be a choice of the user and then have the admin come along and override that. They have to be able to for the purposes of emergency management, but pinning you to a new AZ sort of crosses the line of what the user should own, IMHO. I can see the argument for both cases, but as such, neither seems overly clear to me.\n\nAm I reading you right that your _preference_ is that we do the repining stuff in a separate effort, but you\u0027re not a hard -2 on that?\n\nI\u0027m asking because it seems like you\u0027re simultaneously saying you want all the move operations to have the exact same semantics introduced in the same microversion, which is even more change with this auto-re-pin behavior. That\u0027s a lot to hold this up for so I just want to make sure I\u0027m clear on what you\u0027re willing to accept versus what is your preference.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"41d5b21c40f2b77a46d195b411f27385dcc03b6b","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4b101367_a73dd8bf","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"3250b56d_6f56e693","updated":"2026-10-21 16:15:41.000000000","message":"im not ok with adding AZ to live migration without adding it to cold migrate in the same microverions.\n\nthat indepentent fo any of the ohter chagnes we are dicussing.\n\non `availability_zone`vs `dest_availability_zone` \n\ni dont think availability_zone is any less clear in terms fo beign the lcoation you want to move too.\n\nthe pining semantics are indepentinet form the name.\ni dont think `dest_` add any clarity in the api ref and is just more verbose.\n\nif you wanted to call it `dest_availability_zone`in the request spec i woudl be more ok with that but i dont think that aid clarity in the api request or responce.\n\ni would be ok with sayign the instnace must be unpined to corss az if we must limit scope porvied we have a path to fix that later.\n\nim not ok with adding az to live migrate if we dont at a minium add it to cold migrate as well and preferably evacuate too.\n\ni would like all 3 of live migrate, evacuate and cold migrate to accept an az and host as parmaters.\n\ni dont think that effort shoudl be coupled to the ability to move betwen cells although the fact you are not also adding cross cell evacuate in this proposl is problematic.\n\ni really dislike that move operations depend on cell awarenes today.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"7783fcf84c7d63ddca0f1cc85cbcce0698f8c92b","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0522f768_80f5ced4","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"4b101367_a73dd8bf","updated":"2026-10-28 13:20:59.000000000","message":"\u003e im not ok with adding AZ to live migration without adding it to cold migrate in the same microverions.\n\nSorry this will not fly for me. If we cannot do iterative development and limit the scope of the spec then I\u0027m pretty sure this will not be done at all as we will simply alienate our developer base by asking too much from them. Why we need everything in a single step? Is this some kind of gatekeeping?","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e7233113f02289940e8b2ba01921b1dc939522d7","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"149bfcdc_eacae307","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"68981752_ea9d2c74","updated":"2026-10-21 14:35:22.000000000","message":"well the migration object already has the old/new host and flavor right\n\nhttps://github.com/openstack/nova/blob/master/nova/objects/migration.py#L67-L77\n\nand a flag for if its a corss cell move\nhttps://github.com/openstack/nova/blob/master/nova/objects/migration.py#L88\n\nso we can jsut add the old and new az\n\nand as part of finalisation of the cell mapping on failure we can restore the preior az value if there was a pin.\n\nthe migration object need to exist in both cells so we can read this back even if we have deleted the entries on the destiaion already asyconosly.\n\nfor me this shoudl be part of adding the AZ parmater so if you want to spelit that i think it woudl be ok but i woudl prefer not to punt this if we intennd to add the AZ parmater to the action.\n\nwhile its not ideal im ok with maintaining the \"you can only migrage between azs if your not pinned\" behvior if all you can pass is the host or let the schduler decied. if we add the ability to pass an az i dont think we shoudl make you unpin first to change az. i would be fine with keeping the unshlve behavior where if its fails we dont revert the pinning from the new az. its not the cleanest but tis at least consitent.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"82eb634e2e1c7f716e43421159c70a3cb1895e0a","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9405614d_0d7dd332","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"93ce6181_dca09701","updated":"2026-10-29 19:48:57.000000000","message":"ok, it is more complicated than I thought and I agree not to make this spec solve everything in a single shot. I am ok to tackle it as a separate effort. Asking admin to unpin AZ before migrating to another AZ is not a big pain point. Having it in a single operation is better, but two operations are not so bad.\n\nAnd as it is same as it is in v1 so we are not downgrading anything for admin.\n\nTo support anything (AZ in this case), one of the migration operations should not have a hard requirement to support all migration operations (live/cold migration/evacuation). It makes things hard to develop incrementally.\n\nI do not disagree with the watcher use case (or challenges), but we should not block it to solve other use cases, such as \u0027admin wants to live migrate across cells\u0027. I see here we at least solve the key use case first and then once we support it in cold migration/evacuation then watcher use case also solved.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d80dc09985ed6fd68a288884f74e6f817f5af020","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f25b5226_7e873d26","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"9405614d_0d7dd332","updated":"2026-10-30 16:45:46.000000000","message":"if we want to incremntal progress we shoudl not be inlcuding unrelated feature i this rpoposal\n\nhttps://review.opendev.org/c/openstack/nova-specs/+/1013094/1/specs/2027.1/approved/migrate-to-availability-zone.rst\n\nis the minimal change requried to correctly suprpot az for live migrae cold migrate and evacualte\n\nthis is effectvly the same chagnes i ask for when the topic of adding az came up in yoga for unshleve.\nit even eaiser now that we have a dedicated api for unpin and pining the vms az.\n\n\nif we agree that this is a change that shoudl be made i woudl prefer to make ti first in a seprate spec before considerin adding the new api action this spec propsoes.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"41c79b35d1290e89698c4036fda6583bb53612e5","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e7e3f486_0b7dc87b","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"abf8947f_c922b43c","updated":"2026-10-21 13:12:43.000000000","message":"this is a significant pain point for watcher to suprpot this\nas woudl adding az without supproting it for cold migrate at the same time\n\nif nova does nto handel the unpinnign and pinng for the client then whatre has to orchestrate the unpining, piing and rollback of the same.\nthat means breaking our curent 1:1 mapping betwen watcher actions and api opertions\nas we now woudl have to make live migrate call the new api for pinning and unpining a vm udign the execution of our live migration action.\n\nwatcher currenly uses teh instnace state to determin if we shoudl live or cold migrate a vm\n\nif we do not have the ablity to pass the az for cold migrate then if we expsoe az as a destitiaon in any stragy we entiehr need to do the scdulign to a host in the az ourselve in teh cold migrate case or exclude all stop instnace.\n\nhonestly this is oen of the resaons i was so unhappy with the porposal to nova have the super conductor orstrate this and why i wanted an upcall to the supprot conductor or a external event to propage the statges so we coudl do this propelry.\n\nthis is pretty problematic and a bad admin ux in my opinion as currently propsosed.\n\nit may be a ux we can live with but its not the ux we shoudl be aiming for.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6300e1a912318649bb30107e7ec1131aaa29091e","unresolved":true,"context_lines":[{"line_number":127,"context_line":"    a scheduling failure"},{"line_number":128,"context_line":" 2. The instance must be unpinned before migrating to another AZ"},{"line_number":129,"context_line":""},{"line_number":130,"context_line":"Just like with v1 live migration, even excluding the potential for crossing"},{"line_number":131,"context_line":"cells, we cannot re-pin an instance to an AZ after successful completion of"},{"line_number":132,"context_line":"the live migration operation because the computes have no ability to update"},{"line_number":133,"context_line":"the request spec (where the pin is held) after successful completion. This"},{"line_number":134,"context_line":"differs from operations such as resize or cold migration as the former can"},{"line_number":135,"context_line":"take a very long time to run, will be completed or reverted sometime in the"},{"line_number":136,"context_line":"future, and it is not feasible to have a superconductor thread wait for the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"68981752_ea9d2c74","line":133,"range":{"start_line":130,"start_character":0,"end_line":133,"end_character":69},"in_reply_to":"e7e3f486_0b7dc87b","updated":"2026-10-21 13:49:54.000000000","message":"I\u0027m not okay with a forever upcall to support this, especially as we don\u0027t have the ability to do it today, and v1 would require a similar upcall. I also think this fits within the \"no more orchestraton\" project tenet:\n\nhttps://docs.openstack.org/nova/15.0.3/project_scope.html#no-more-orchestration\n\nWe\u0027ve certainly argued this before when people asked us to \"do X, then Y, then Z\".\n\nThat said, the only reasonable way I can see to do this is to make it like the old_cell_id field - we leave a tombstone in ReqSpec that basically says \"if the instance made it to AZ 2, then consider that its current pin, and if not, continue to assume 1\". We can convert-on-read in the same way we do the cell mapping, and such a lazy conversion fits well with our desired goals I think.\n\nIf we do that, I\u0027ll also ask to punt that part to a later change per Sylvain\u0027s ask here already. Today, you can\u0027t live migrate with a pin, so what is written here would be consistent with that while we re-plumb. Then we can follow up with another change where migrating with a pin is allowed, and we\u0027ll do the tombstone + lazy conversion.\n\nHow about that?","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6080756f46e9a1f5f51b3c55a2d62852ae4690b7","unresolved":true,"context_lines":[{"line_number":285,"context_line":"signal the confirm/revert behavior, setting the ``consumer_type`` will help"},{"line_number":286,"context_line":"increase visibility. Further, we could propose a feature in placement that"},{"line_number":287,"context_line":"requires ``service_role`` (or some other authorization) to delete allocations"},{"line_number":288,"context_line":"with ``consumer_type\u003d\u0027migration\u0027`` in the future."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"}],"source_content_type":"text/x-rst","patch_set":3,"id":"55dc9e6e_e2db55c3","line":288,"updated":"2026-10-20 14:20:45.000000000","message":"On the PTG we mentioned both \"migration\" and \"nova\" as consumer_type. I guess migration is more precise. \n* I\u0027m wondering if we will set some type on the non migration allocations created by nova\n* also I\u0027m wondering for future proofing of the consumer type, if other projects start creating allocations in placement we might want to include into the type that this is a nova owned migration allocation, like \"nova:migration\"","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"6300e1a912318649bb30107e7ec1131aaa29091e","unresolved":false,"context_lines":[{"line_number":285,"context_line":"signal the confirm/revert behavior, setting the ``consumer_type`` will help"},{"line_number":286,"context_line":"increase visibility. Further, we could propose a feature in placement that"},{"line_number":287,"context_line":"requires ``service_role`` (or some other authorization) to delete allocations"},{"line_number":288,"context_line":"with ``consumer_type\u003d\u0027migration\u0027`` in the future."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"}],"source_content_type":"text/x-rst","patch_set":3,"id":"a39d85fc_5cbcf3a8","line":288,"in_reply_to":"0ca319d1_116a22c7","updated":"2026-10-21 13:49:54.000000000","message":"ACK, TBH I mis-read the original spec (linked below) and thought it had existing enumerated values (like traits) but it looks like it was just giving a sample DB table 😉\n\nSo yeah `nova:instance` and `nova:migration` sound good to me.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9e7e7e1e1c99930fe04c39d4e80f07191e0e8b39","unresolved":true,"context_lines":[{"line_number":285,"context_line":"signal the confirm/revert behavior, setting the ``consumer_type`` will help"},{"line_number":286,"context_line":"increase visibility. Further, we could propose a feature in placement that"},{"line_number":287,"context_line":"requires ``service_role`` (or some other authorization) to delete allocations"},{"line_number":288,"context_line":"with ``consumer_type\u003d\u0027migration\u0027`` in the future."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f09eb29e_20cd8b55","line":288,"in_reply_to":"55dc9e6e_e2db55c3","updated":"2026-10-20 14:28:57.000000000","message":"Yeah, when I said nova in the PTG I had forgotten that the values were constrained and weren\u0027t just free-form. Looking at this after the fact, I assume migration is the right thing to use, and it distinguishes them further as \"these are for a migration not an instance.\"\n\nBut, I was planning to treat this and the instance name migration as separate parallel efforts as I don\u0027t think either will have a specific tight coupling here. We already do the allocation creation for existing migrations so I think we should be able to transition to that independently.\n\nDo you want me to change something about this here or make the wording less concrete to leave room?","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"31b7b5190f67fd917a11e3805c92f627700105bf","unresolved":true,"context_lines":[{"line_number":285,"context_line":"signal the confirm/revert behavior, setting the ``consumer_type`` will help"},{"line_number":286,"context_line":"increase visibility. Further, we could propose a feature in placement that"},{"line_number":287,"context_line":"requires ``service_role`` (or some other authorization) to delete allocations"},{"line_number":288,"context_line":"with ``consumer_type\u003d\u0027migration\u0027`` in the future."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"}],"source_content_type":"text/x-rst","patch_set":3,"id":"dad47f95_3313ab5b","line":288,"in_reply_to":"69d53ec8_d3d72643","updated":"2026-10-28 10:20:43.000000000","message":"My bed about NOVA, I agree that we should use COMPUTE instead. Lets go with COMPUTE_INSTANCE and COMPUTE_MIGRATION that is a lot more future proof than the super generic term of INSTANCE (everything is an instance of something)\n\nI\u0027m not really attached to the spec we wrote in xena. I think we more experienced now and we have the power to make smarter decision. So keeping INSTANCE just because we wrote that many years ago is not a valid reason for me to not to change that. Is there a good technical reason keeping INSTANCE?","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"ae748bcec3e699f44e3c07720280b2f11d8ae42b","unresolved":false,"context_lines":[{"line_number":285,"context_line":"signal the confirm/revert behavior, setting the ``consumer_type`` will help"},{"line_number":286,"context_line":"increase visibility. Further, we could propose a feature in placement that"},{"line_number":287,"context_line":"requires ``service_role`` (or some other authorization) to delete allocations"},{"line_number":288,"context_line":"with ``consumer_type\u003d\u0027migration\u0027`` in the future."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b5a175a0_5b5e0909","line":288,"in_reply_to":"a39d85fc_5cbcf3a8","updated":"2026-10-21 15:41:36.000000000","message":"Er, looks like we get `[A-Z_]+` for consumer type names. So, we could do `NOVA_INSTANCE` and `NOVA_MIGRATION` but that\u0027s about it.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"41d5b21c40f2b77a46d195b411f27385dcc03b6b","unresolved":true,"context_lines":[{"line_number":285,"context_line":"signal the confirm/revert behavior, setting the ``consumer_type`` will help"},{"line_number":286,"context_line":"increase visibility. Further, we could propose a feature in placement that"},{"line_number":287,"context_line":"requires ``service_role`` (or some other authorization) to delete allocations"},{"line_number":288,"context_line":"with ``consumer_type\u003d\u0027migration\u0027`` in the future."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"}],"source_content_type":"text/x-rst","patch_set":3,"id":"69d53ec8_d3d72643","line":288,"in_reply_to":"b5a175a0_5b5e0909","updated":"2026-10-21 16:15:41.000000000","message":"so when i brought htis up in the ptg and on earlier version i specificly said instance and migration becuase the exac ct expected values were docuemtned in the placement spec\n\nhttps://docs.openstack.org/placement/latest/specs/xena/implemented/support-consumer-types.html\n\nso it has to be `INSTANCE` or `MIGRATION`\n\nso this was not an open question in my mind it was somethng we decied in xena\n\nim not sure if adding nova is approate since we have a general rule of not using the project code names in any api values.\n\nif we were to deviate form teh spec i think `COMPUTE_`, using the service-type woudl be more correct but again i perfer `INSTANCE` and `MIGRATION` as the actual values.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9b9698eeb7d7c93d57333ca14fb6aacbcb5a90e6","unresolved":true,"context_lines":[{"line_number":285,"context_line":"signal the confirm/revert behavior, setting the ``consumer_type`` will help"},{"line_number":286,"context_line":"increase visibility. Further, we could propose a feature in placement that"},{"line_number":287,"context_line":"requires ``service_role`` (or some other authorization) to delete allocations"},{"line_number":288,"context_line":"with ``consumer_type\u003d\u0027migration\u0027`` in the future."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9adab1c6_1b73dce6","line":288,"in_reply_to":"dad47f95_3313ab5b","updated":"2026-10-30 17:13:49.000000000","message":"not really  \n\nlooking at teh 1.38 api micriovion examples\n\nhttps://docs.openstack.org/api-ref/placement/#id68\n\nwe say\n```\nA string that consists of numbers, A-Z, and _ describing what kind of consumer is creating, or has created, allocations using a quantity of inventory. The string is determined by the client when writing allocations and it is up to the client to ensure correct choices amongst collaborating services. For example, the compute service may choose to type some consumers ‘INSTANCE’ and others ‘MIGRATION’.\n```\n\nand use tha tin the request exampels but i woudl have to check if we ever encoded that in an enum in the db or api schema or if its actully free form\n\nif we have not `COMPUTE_INSTANCE` and `COMPUTE_MIGRATION`\n\nbut form me to be ok with use using placement ot driver our state machine like this which i condier a violaition of our current acitsture we need to make sure that the servie ole is requried to delete allcoatiosn asocated with nova instance or migrations.\n\nso i dont agree that this is a parallel effort.\n\nif the chioce is to depend on the allcoation deleteion to trigger the rollback or postmigration cleanup then we need to tightent the congract here.\n\nif we go some other direction for that then i agree this is just a nice to have an paralel effort. i though i experss that clarly durign the ptg but per haps that did not travel well.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f74b3455dff1fc811c1050e837aa0209b68d3eba","unresolved":true,"context_lines":[{"line_number":285,"context_line":"signal the confirm/revert behavior, setting the ``consumer_type`` will help"},{"line_number":286,"context_line":"increase visibility. Further, we could propose a feature in placement that"},{"line_number":287,"context_line":"requires ``service_role`` (or some other authorization) to delete allocations"},{"line_number":288,"context_line":"with ``consumer_type\u003d\u0027migration\u0027`` in the future."},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"}],"source_content_type":"text/x-rst","patch_set":3,"id":"0ca319d1_116a22c7","line":288,"in_reply_to":"f09eb29e_20cd8b55","updated":"2026-10-21 09:06:45.000000000","message":"\u003e Yeah, when I said nova in the PTG I had forgotten that the values were constrained and weren\u0027t just free-form. Looking at this after the fact, I assume migration is the right thing to use, and it distinguishes them further as \"these are for a migration not an instance.\"\n\nBased on the API doc it is a free form string of 255 chars: \n\u003e A string that consists of numbers, A-Z, and _ describing what kind of consumer is creating, or has created, allocations using a quantity of inventory. The string is determined by the client when writing allocations and it is up to the client to ensure correct choices amongst collaborating services. For example, the compute service may choose to type some consumers ‘INSTANCE’ and others ‘MIGRATION’.\n\nhttps://docs.openstack.org/api-ref/placement/#manage-allocations\n\n\u003e \n\u003e But, I was planning to treat this and the instance name migration as separate parallel efforts as I don\u0027t think either will have a specific tight coupling here. We already do the allocation creation for existing migrations so I think we should be able to transition to that independently.\n\u003e \n\u003e Do you want me to change something about this here or make the wording less concrete to leave room?\n\nI agree that this is a separate effort. So we can move the details of this discussion to whatever place that tracks that separate effort. \n\nBut if this is a free form field then I would really want to consider \"nova:instance\" and \"nova:migration\" as consumer type over \"instance\" and \"migration\" for future proofing for other projects making allocations.\n\nNothing to add here in this spec.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"6080756f46e9a1f5f51b3c55a2d62852ae4690b7","unresolved":true,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"},{"line_number":292,"context_line":"be reviewed, discussed, and landed independently."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Known issue: instance names"},{"line_number":295,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"015b0284_2f09b5dd","line":292,"updated":"2026-10-20 14:20:45.000000000","message":"+1","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":9708,"name":"Balazs Gibizer","display_name":"gibi","email":"gibizer@gmail.com","username":"gibi"},"change_message_id":"f74b3455dff1fc811c1050e837aa0209b68d3eba","unresolved":false,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"},{"line_number":292,"context_line":"be reviewed, discussed, and landed independently."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Known issue: instance names"},{"line_number":295,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fb968c0b_d2357ead","line":292,"in_reply_to":"015b0284_2f09b5dd","updated":"2026-10-21 09:06:45.000000000","message":"Done","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"41d5b21c40f2b77a46d195b411f27385dcc03b6b","unresolved":true,"context_lines":[{"line_number":289,"context_line":""},{"line_number":290,"context_line":"Because this change isn\u0027t a direct dependency of this work, it will be kept"},{"line_number":291,"context_line":"separate from the serialized stack of changes for the v2 operation and can"},{"line_number":292,"context_line":"be reviewed, discussed, and landed independently."},{"line_number":293,"context_line":""},{"line_number":294,"context_line":"Known issue: instance names"},{"line_number":295,"context_line":"---------------------------"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7016303d_2d37336d","line":292,"in_reply_to":"fb968c0b_d2357ead","updated":"2026-10-21 16:15:41.000000000","message":"ideally we woudl do this before the rest of this work not after.\ni do see this and the intoduction of the new policy rules to prevent admins form delting allcoations with the `MIGRATION` type as an impornat safey mechanisum that we shoudl land in the same cycle ideally before we buidl on top of it.\n\nim not really happy with merging this code without that in place so its an indepented effor tbut i diagree that is not a direct depency.\n\nwe could also address my main objection to useing placmenet allcoation to orhstrat nova internal state machine by making the deletion of all allocation require the service role by default but im not sure if that is a bigger change.\n\nmy suggestion to start seting consumer types was so we coudl make the plocy chagne more targets to only migrations since that was the operation that need protecting.","commit_id":"ce20cd87d98cb333bbe75941b9a502847a2acfb9"}]}