)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"51db889bd5518ca0ed89465386028a1227637a2f","unresolved":true,"context_lines":[{"line_number":9,"context_line":"Operators need to select a destination availability zone for cold"},{"line_number":10,"context_line":"migration, live migration, and evacuation without choosing a compute"},{"line_number":11,"context_line":"host themselves."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This spec proposes a microversion that accepts an availability zone for"},{"line_number":14,"context_line":"these operations and reuses destination aggregate constraints. Persistent"},{"line_number":15,"context_line":"AZ pins remain unchanged, and flavor-changing resize stays outside scope."},{"line_number":16,"context_line":"The microversion also makes all accepted evacuation requests return"},{"line_number":17,"context_line":"HTTP 202 instead of HTTP 200, preserving older microversion behavior."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"APIImpact"},{"line_number":20,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"b3bd9d2c_486dd114","line":17,"range":{"start_line":12,"start_character":1,"end_line":17,"end_character":69},"updated":"2026-10-30 18:42:54.000000000","message":"nit: can you wrap at \u003c\u003d 72 characters","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df66714f546b7034ec83f90176584a5d19102e7b","unresolved":false,"context_lines":[{"line_number":9,"context_line":"Operators need to select a destination availability zone for cold"},{"line_number":10,"context_line":"migration, live migration, and evacuation without choosing a compute"},{"line_number":11,"context_line":"host themselves."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"This spec proposes a microversion that accepts an availability zone for"},{"line_number":14,"context_line":"these operations and reuses destination aggregate constraints. Persistent"},{"line_number":15,"context_line":"AZ pins remain unchanged, and flavor-changing resize stays outside scope."},{"line_number":16,"context_line":"The microversion also makes all accepted evacuation requests return"},{"line_number":17,"context_line":"HTTP 202 instead of HTTP 200, preserving older microversion behavior."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"APIImpact"},{"line_number":20,"context_line":""}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"ad286c30_eaeb37e9","line":17,"range":{"start_line":12,"start_character":1,"end_line":17,"end_character":69},"in_reply_to":"b3bd9d2c_486dd114","updated":"2026-11-03 18:53:05.000000000","message":"Done","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"51db889bd5518ca0ed89465386028a1227637a2f","unresolved":true,"context_lines":[{"line_number":16,"context_line":"The microversion also makes all accepted evacuation requests return"},{"line_number":17,"context_line":"HTTP 202 instead of HTTP 200, preserving older microversion behavior."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"APIImpact"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Assisted-By: Pi openai-codex/gpt-6.1-sol"},{"line_number":22,"context_line":"Change-Id: Idcc7aae82670dff84a0b1a4a21487883584ecb05"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"ef2adec4_2b71ff93","line":19,"updated":"2026-10-30 18:42:54.000000000","message":"nit: do we still use these? I haven\u0027t used them in years.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b8fdf1a56c0bd2f3cd0926608e00fad0d3bedac6","unresolved":true,"context_lines":[{"line_number":16,"context_line":"The microversion also makes all accepted evacuation requests return"},{"line_number":17,"context_line":"HTTP 202 instead of HTTP 200, preserving older microversion behavior."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"APIImpact"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Assisted-By: Pi openai-codex/gpt-6.1-sol"},{"line_number":22,"context_line":"Change-Id: Idcc7aae82670dff84a0b1a4a21487883584ecb05"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"ff3167be_1418412e","line":19,"in_reply_to":"ef2adec4_2b71ff93","updated":"2026-10-31 00:10:31.000000000","message":"technialy no but i have this in my commit message skill becaues reasons\n\nill drop this.\n\nwe took down the automation that automaticlly filed docs bugs  based on this before you dispaneded the docs team so it has not really done anythign flor 8 years or more.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df66714f546b7034ec83f90176584a5d19102e7b","unresolved":false,"context_lines":[{"line_number":16,"context_line":"The microversion also makes all accepted evacuation requests return"},{"line_number":17,"context_line":"HTTP 202 instead of HTTP 200, preserving older microversion behavior."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"APIImpact"},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Assisted-By: Pi openai-codex/gpt-6.1-sol"},{"line_number":22,"context_line":"Change-Id: Idcc7aae82670dff84a0b1a4a21487883584ecb05"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"dc41df29_4aec48b3","line":19,"in_reply_to":"ff3167be_1418412e","updated":"2026-11-03 18:53:05.000000000","message":"Done","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8a70371fca82b6c9e6a217c9831592e015bd22e9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a967c258_365e67bc","updated":"2026-10-30 18:53:04.000000000","message":"Few more notes from looking at how this could be done in code.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"81fa3eb720e02111f991057cf0517d08ef6cc30a","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"01356ffe_4fe5e778","updated":"2026-11-03 12:23:13.000000000","message":"Im going to respin this to tighten up the wording and and address Stephen\u0027s comments","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"51db889bd5518ca0ed89465386028a1227637a2f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4c7bbf3f_50362eec","updated":"2026-10-30 18:42:54.000000000","message":"Makes sense to me. Couple of notes inline. I\u0027m intentionally not +2ing because (a) there\u0027s currently no assignee and (b) I don\u0027t want to block the live migration v2 rework for this (though I do think it should likely be done first/alongside that if we were going to do it)","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9a505d5514a805f6e0efbbe00de65839518cb428","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":2,"id":"e8b52a75_05502846","updated":"2026-11-10 12:54:26.000000000","message":"as noted on irc im going to make some adjusgment and leave this uncheaged for a day or two while i set up a multi node devstack and work on the openstack client and tempest tests.\n\ni plan to rework this on thrusday so if there are any other comments or request ill incoperate them then.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5300f1476bccddfa1c508485b4e81008155951d1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"c695b5a2_c4f03be7","updated":"2026-11-12 17:33:12.000000000","message":"couple of comments","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6ddf27416877ae682142541f7164d3b8a0787ab1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"ee0788f7_d4923c25","updated":"2026-11-10 11:22:28.000000000","message":"just a few comments at the moment, I\u0027ll continue to look at the spec.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a0f776bb_4cac8b4b","updated":"2026-11-13 02:59:38.000000000","message":"Thanks, Sean, for the detailed spec. A few comments, especially about having a single operation for pin/unpin/moving-to-cross-az, since those are single operations for users.","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7455aaa24fac2e65ab88e038187d80648785805b","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"fdb7e875_809288c0","in_reply_to":"a0f776bb_4cac8b4b","updated":"2026-11-13 11:57:02.000000000","message":"to be clear any requirement we include in this spec also applies to my accpatend for includign AZ in teh cross cell spec.\n\nthis spec exists to do 2 things, capture the deatils that were missing form the cross cell spec with regards to how cross az movs shoudl work, and resovle my direct objecto to adding AZ as a partmer only ton live migration.\n\ni prefer the idea that nova would pin and unpin based on success however dan directly objected to that when i rased it on there spec in \nhttps://review.opendev.org/c/openstack/nova-specs/+/1008081/comment/09a9666a_bed65891/\n\nif we require that nwo then the cross cell series would also have to be updated.\nthis spec was desinged to accoutn for the feedback form teh dicsoss in the corss cell spec to reolve one of the open action time form the ptg which was explcitly to split out the az part so we could have this detailed dicssions.\n\nso now im getting conclicting feedback and im wondering shoudl i be restoring my -2 on https://review.opendev.org/c/openstack/nova-specs/+/1008081 to signify that we are not closer to concent on the az mechanis then we were before or shoudl i focus in the minimal change that i required to supprot AZ to be ok with progressign with that spec?","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"877de87c8f272b1eec7bebdb6ac6daa267acc4c4","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"5119bb29_80bd393b","in_reply_to":"fdb7e875_809288c0","updated":"2026-11-13 16:33:50.000000000","message":"I am not saying we should do this for v1 live migration, but not for CCLM. I am saying we should leave live migrations as they are, since they\u0027re complex. I do not understand why it is linked to the CCLM proposal.\n\nAnyway, I don\u0027t want to -2 any proposal (this or CCLM); as I mentioned, if the majority thinks the current proposal is OK, I\u0027m happy to go with the majority.","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"}],"specs/2027.1/approved/migrate-to-availability-zone.rst":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8a70371fca82b6c9e6a217c9831592e015bd22e9","unresolved":true,"context_lines":[{"line_number":55,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"A new API microversion will add an optional ``availability_zone`` parameter to"},{"line_number":58,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Callers will be"},{"line_number":59,"context_line":"able to specify a zone, a host, or both. When both are supplied, the API will"},{"line_number":60,"context_line":"require the host to belong to that zone. Authorization and host validation"},{"line_number":61,"context_line":"will still run when the requested AZ matches the persistent pin."},{"line_number":62,"context_line":"Host-only and untargeted migration behavior will remain unchanged."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"d8a12d06_5aa7b46c","line":60,"range":{"start_line":58,"start_character":78,"end_line":60,"end_character":74},"updated":"2026-10-30 18:53:04.000000000","message":"Is this not redundant? A host can only belong to a single AZ, right? Couldn\u0027t we say this is either-or?","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df66714f546b7034ec83f90176584a5d19102e7b","unresolved":false,"context_lines":[{"line_number":55,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"A new API microversion will add an optional ``availability_zone`` parameter to"},{"line_number":58,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Callers will be"},{"line_number":59,"context_line":"able to specify a zone, a host, or both. When both are supplied, the API will"},{"line_number":60,"context_line":"require the host to belong to that zone. Authorization and host validation"},{"line_number":61,"context_line":"will still run when the requested AZ matches the persistent pin."},{"line_number":62,"context_line":"Host-only and untargeted migration behavior will remain unchanged."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fe355021_a707aded","line":60,"range":{"start_line":58,"start_character":78,"end_line":60,"end_character":74},"in_reply_to":"a1f6d3f2_54a69d59","updated":"2026-11-03 18:53:05.000000000","message":"Done","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b8fdf1a56c0bd2f3cd0926608e00fad0d3bedac6","unresolved":true,"context_lines":[{"line_number":55,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"A new API microversion will add an optional ``availability_zone`` parameter to"},{"line_number":58,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Callers will be"},{"line_number":59,"context_line":"able to specify a zone, a host, or both. When both are supplied, the API will"},{"line_number":60,"context_line":"require the host to belong to that zone. Authorization and host validation"},{"line_number":61,"context_line":"will still run when the requested AZ matches the persistent pin."},{"line_number":62,"context_line":"Host-only and untargeted migration behavior will remain unchanged."},{"line_number":63,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"a1f6d3f2_54a69d59","line":60,"range":{"start_line":58,"start_character":78,"end_line":60,"end_character":74},"in_reply_to":"d8a12d06_5aa7b46c","updated":"2026-10-31 00:10:31.000000000","message":"we could i specified it this way just because that is what dan did in there spec.\n\nbut we could make them a optional mutally exclsive goup \n\nso you can pass host or az or neither.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"51db889bd5518ca0ed89465386028a1227637a2f","unresolved":true,"context_lines":[{"line_number":194,"context_line":"    {"},{"line_number":195,"context_line":"        \"os-migrateLive\": {"},{"line_number":196,"context_line":"            \"host\": null,"},{"line_number":197,"context_line":"            \"block_migration\": \"auto\","},{"line_number":198,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":199,"context_line":"        }"},{"line_number":200,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0842ce06_a21f151a","line":197,"updated":"2026-10-30 18:42:54.000000000","message":"nit: if (if! 😀) this were to slot in before the live migration v2 microversion, I\u0027d probably cull this too. It\u0027s not needed/confusing nowadays.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b8fdf1a56c0bd2f3cd0926608e00fad0d3bedac6","unresolved":true,"context_lines":[{"line_number":194,"context_line":"    {"},{"line_number":195,"context_line":"        \"os-migrateLive\": {"},{"line_number":196,"context_line":"            \"host\": null,"},{"line_number":197,"context_line":"            \"block_migration\": \"auto\","},{"line_number":198,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":199,"context_line":"        }"},{"line_number":200,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4a451aef_c88a3346","line":197,"in_reply_to":"0842ce06_a21f151a","updated":"2026-10-31 00:10:31.000000000","message":"ya its jsut the current default when yuou use the new microverion but i can drop this your right htat ists not needed in the example.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df66714f546b7034ec83f90176584a5d19102e7b","unresolved":false,"context_lines":[{"line_number":194,"context_line":"    {"},{"line_number":195,"context_line":"        \"os-migrateLive\": {"},{"line_number":196,"context_line":"            \"host\": null,"},{"line_number":197,"context_line":"            \"block_migration\": \"auto\","},{"line_number":198,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":199,"context_line":"        }"},{"line_number":200,"context_line":"    }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"e24ab86d_2a5ebeaf","line":197,"in_reply_to":"4a451aef_c88a3346","updated":"2026-11-03 18:53:05.000000000","message":"actully its currenly a mandatory parmater that must be passed as auto if you want it to work corectly in all cases so i have adjusted the spec to make it optional in teh request payload\n\nthe sdk/osc hid this form us day to day.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"51db889bd5518ca0ed89465386028a1227637a2f","unresolved":true,"context_lines":[{"line_number":209,"context_line":"        }"},{"line_number":210,"context_line":"    }"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Evacuation\u0027s host parameter is optional and will remain so. Callers will also"},{"line_number":213,"context_line":"be able to specify a non-null host with the zone for any of the three actions."},{"line_number":214,"context_line":"For example:"},{"line_number":215,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3f2ff2b9_3948f79d","line":212,"updated":"2026-10-30 18:42:54.000000000","message":"nit: bit of an odd callout. `host` is also optional for cold and live migration, right?","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df66714f546b7034ec83f90176584a5d19102e7b","unresolved":true,"context_lines":[{"line_number":209,"context_line":"        }"},{"line_number":210,"context_line":"    }"},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Evacuation\u0027s host parameter is optional and will remain so. Callers will also"},{"line_number":213,"context_line":"be able to specify a non-null host with the zone for any of the three actions."},{"line_number":214,"context_line":"For example:"},{"line_number":215,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ae3b9a44_11a92238","line":212,"in_reply_to":"3f2ff2b9_3948f79d","updated":"2026-11-03 18:53:05.000000000","message":"its optional for cold migrage and can be omited or passed as null but its requried in the live migration payload also adressed.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"51db889bd5518ca0ed89465386028a1227637a2f","unresolved":true,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"* HTTP 400 if the requested zone does not exist or a supplied host does not"},{"line_number":241,"context_line":"  belong to it."},{"line_number":242,"context_line":"* HTTP 400 if the destination conflicts with the server\u0027s persistent AZ pin."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Existing errors will remain applicable, including HTTP 403 for a policy denial,"},{"line_number":245,"context_line":"HTTP 404 for a missing server, and HTTP 409 for an incompatible server state"}],"source_content_type":"text/x-rst","patch_set":1,"id":"79739f6b_3edc960d","line":242,"updated":"2026-10-30 18:42:54.000000000","message":"```suggestion\n* HTTP 400 if the the request availability zone conflicts with the server\u0027s\n  persistent AZ pin.\n```\n\nRight? Asking for a `host` in another AZ is already an exception iirc.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df66714f546b7034ec83f90176584a5d19102e7b","unresolved":false,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"* HTTP 400 if the requested zone does not exist or a supplied host does not"},{"line_number":241,"context_line":"  belong to it."},{"line_number":242,"context_line":"* HTTP 400 if the destination conflicts with the server\u0027s persistent AZ pin."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Existing errors will remain applicable, including HTTP 403 for a policy denial,"},{"line_number":245,"context_line":"HTTP 404 for a missing server, and HTTP 409 for an incompatible server state"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bfc3b57c_f5b59a6b","line":242,"in_reply_to":"0b479da0_453e2f71","updated":"2026-11-03 18:53:05.000000000","message":"Acknowledged","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b8fdf1a56c0bd2f3cd0926608e00fad0d3bedac6","unresolved":true,"context_lines":[{"line_number":239,"context_line":""},{"line_number":240,"context_line":"* HTTP 400 if the requested zone does not exist or a supplied host does not"},{"line_number":241,"context_line":"  belong to it."},{"line_number":242,"context_line":"* HTTP 400 if the destination conflicts with the server\u0027s persistent AZ pin."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Existing errors will remain applicable, including HTTP 403 for a policy denial,"},{"line_number":245,"context_line":"HTTP 404 for a missing server, and HTTP 409 for an incompatible server state"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0b479da0_453e2f71","line":242,"in_reply_to":"79739f6b_3edc960d","updated":"2026-10-31 00:10:31.000000000","message":"so if a vm is not pinned to a az it can be live meigated to another az via passing the host.\n\nif it is pinned to an az asking for a host in a diffent az is an error.\n\nthat also the other reaosn for validatign both host and az if we supprot both in the same request, jsut maintaining the check we alerady do.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"51db889bd5518ca0ed89465386028a1227637a2f","unresolved":true,"context_lines":[{"line_number":240,"context_line":"* HTTP 400 if the requested zone does not exist or a supplied host does not"},{"line_number":241,"context_line":"  belong to it."},{"line_number":242,"context_line":"* HTTP 400 if the destination conflicts with the server\u0027s persistent AZ pin."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Existing errors will remain applicable, including HTTP 403 for a policy denial,"},{"line_number":245,"context_line":"HTTP 404 for a missing server, and HTTP 409 for an incompatible server state"},{"line_number":246,"context_line":"or when an existing lock check rejects the request. Lock behavior will remain"},{"line_number":247,"context_line":"unchanged. A valid destination zone with no suitable host will follow"},{"line_number":248,"context_line":"the existing asynchronous migration failure path. The caller can inspect"},{"line_number":249,"context_line":"instance actions for the failure. The operation will not fall back to another"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6dce76f2_82860542","line":246,"range":{"start_line":243,"start_character":1,"end_line":246,"end_character":77},"updated":"2026-10-30 18:42:54.000000000","message":"nit: I think these lines are redundant (it\u0027s implicit IMO)","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df66714f546b7034ec83f90176584a5d19102e7b","unresolved":false,"context_lines":[{"line_number":240,"context_line":"* HTTP 400 if the requested zone does not exist or a supplied host does not"},{"line_number":241,"context_line":"  belong to it."},{"line_number":242,"context_line":"* HTTP 400 if the destination conflicts with the server\u0027s persistent AZ pin."},{"line_number":243,"context_line":""},{"line_number":244,"context_line":"Existing errors will remain applicable, including HTTP 403 for a policy denial,"},{"line_number":245,"context_line":"HTTP 404 for a missing server, and HTTP 409 for an incompatible server state"},{"line_number":246,"context_line":"or when an existing lock check rejects the request. Lock behavior will remain"},{"line_number":247,"context_line":"unchanged. A valid destination zone with no suitable host will follow"},{"line_number":248,"context_line":"the existing asynchronous migration failure path. The caller can inspect"},{"line_number":249,"context_line":"instance actions for the failure. The operation will not fall back to another"}],"source_content_type":"text/x-rst","patch_set":1,"id":"51a66a9d_a8ff15aa","line":246,"range":{"start_line":243,"start_character":1,"end_line":246,"end_character":77},"in_reply_to":"6dce76f2_82860542","updated":"2026-11-03 18:53:05.000000000","message":"Acknowledged","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8a70371fca82b6c9e6a217c9831592e015bd22e9","unresolved":true,"context_lines":[{"line_number":244,"context_line":"Existing errors will remain applicable, including HTTP 403 for a policy denial,"},{"line_number":245,"context_line":"HTTP 404 for a missing server, and HTTP 409 for an incompatible server state"},{"line_number":246,"context_line":"or when an existing lock check rejects the request. Lock behavior will remain"},{"line_number":247,"context_line":"unchanged. A valid destination zone with no suitable host will follow"},{"line_number":248,"context_line":"the existing asynchronous migration failure path. The caller can inspect"},{"line_number":249,"context_line":"instance actions for the failure. The operation will not fall back to another"},{"line_number":250,"context_line":"zone."},{"line_number":251,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"6aac6c64_b9176992","line":248,"range":{"start_line":247,"start_character":11,"end_line":248,"end_character":49},"updated":"2026-10-30 18:53:04.000000000","message":"So just to be clear, a non-existent AZ will reject the request synchronously, while a valid AZ with full hosts will reject it async. Right? If so, what about an AZ whose hosts are all disabled? Sync or async?","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"b8fdf1a56c0bd2f3cd0926608e00fad0d3bedac6","unresolved":true,"context_lines":[{"line_number":244,"context_line":"Existing errors will remain applicable, including HTTP 403 for a policy denial,"},{"line_number":245,"context_line":"HTTP 404 for a missing server, and HTTP 409 for an incompatible server state"},{"line_number":246,"context_line":"or when an existing lock check rejects the request. Lock behavior will remain"},{"line_number":247,"context_line":"unchanged. A valid destination zone with no suitable host will follow"},{"line_number":248,"context_line":"the existing asynchronous migration failure path. The caller can inspect"},{"line_number":249,"context_line":"instance actions for the failure. The operation will not fall back to another"},{"line_number":250,"context_line":"zone."},{"line_number":251,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"8cf0f4fa_871124c7","line":248,"range":{"start_line":247,"start_character":11,"end_line":248,"end_character":49},"in_reply_to":"6aac6c64_b9176992","updated":"2026-10-31 00:10:31.000000000","message":"yep if the az exist but none of the host are valid say because your vms need a gpu and none of them are free the migration will fail async because it will internaly get a no valid host.\n\nif the az does not exsit at all we can reject that syncrounsly.\n\nso typos of the az name would be a 400 bad request a full az would be a 202 and then the migration goes to failed asd it does today if it cant select a host.","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"df66714f546b7034ec83f90176584a5d19102e7b","unresolved":false,"context_lines":[{"line_number":244,"context_line":"Existing errors will remain applicable, including HTTP 403 for a policy denial,"},{"line_number":245,"context_line":"HTTP 404 for a missing server, and HTTP 409 for an incompatible server state"},{"line_number":246,"context_line":"or when an existing lock check rejects the request. Lock behavior will remain"},{"line_number":247,"context_line":"unchanged. A valid destination zone with no suitable host will follow"},{"line_number":248,"context_line":"the existing asynchronous migration failure path. The caller can inspect"},{"line_number":249,"context_line":"instance actions for the failure. The operation will not fall back to another"},{"line_number":250,"context_line":"zone."},{"line_number":251,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"f64960a9_a2d19346","line":248,"range":{"start_line":247,"start_character":11,"end_line":248,"end_character":49},"in_reply_to":"8cf0f4fa_871124c7","updated":"2026-11-03 18:53:05.000000000","message":"Done","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"51db889bd5518ca0ed89465386028a1227637a2f","unresolved":false,"context_lines":[{"line_number":283,"context_line":"---------------------"},{"line_number":284,"context_line":""},{"line_number":285,"context_line":"A separate client change could expose an ``--availability-zone`` option for"},{"line_number":286,"context_line":"cold migration, live migration, and evacuation. Client implementation is"},{"line_number":287,"context_line":"outside this proposal. Clients using the new microversion will need to accept"},{"line_number":288,"context_line":"HTTP 202 for evacuation, including requests without an AZ."},{"line_number":289,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"71ed44fc_55ba1eb5","line":286,"updated":"2026-10-30 18:42:54.000000000","message":"Yes. But please do it 😉","commit_id":"1cef08c970d9d3deb687f7f9940ac105ffdff7ad"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6ddf27416877ae682142541f7164d3b8a0787ab1","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Selecting a host requires knowledge of the compute hosts in the destination"},{"line_number":28,"context_line":"zone and prevents the scheduler from choosing among them."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Technical debt"},{"line_number":31,"context_line":"--------------"},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"Cold and live migration reject locked servers for non-admin users, but"}],"source_content_type":"text/x-rst","patch_set":2,"id":"63b539ef_ec8398a0","line":30,"updated":"2026-11-10 11:22:28.000000000","message":"looks not an existing section from the template but meh.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e7f48c29df077690176135f9b53c878f12124613","unresolved":false,"context_lines":[{"line_number":27,"context_line":"Selecting a host requires knowledge of the compute hosts in the destination"},{"line_number":28,"context_line":"zone and prevents the scheduler from choosing among them."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":"Technical debt"},{"line_number":31,"context_line":"--------------"},{"line_number":32,"context_line":""},{"line_number":33,"context_line":"Cold and live migration reject locked servers for non-admin users, but"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bce536b0_ce4fec31","line":30,"in_reply_to":"63b539ef_ec8398a0","updated":"2026-11-11 15:09:19.000000000","message":"(note that we intentionally allow unknown sections at `h3` and lower so we can stick in additional sections like this where relevant)","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6ddf27416877ae682142541f7164d3b8a0787ab1","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"A new API microversion will add an optional ``availability_zone`` parameter to"},{"line_number":57,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Users will be"},{"line_number":58,"context_line":"able to specify a zone, a host, or neither. The host and AZ fields will be"},{"line_number":59,"context_line":"mutually exclusive because a host already identifies its destination zone."},{"line_number":60,"context_line":"Host-only and untargeted scheduling behavior will remain unchanged."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"572e40af_e17c415b","line":58,"range":{"start_line":58,"start_character":23,"end_line":58,"end_character":31},"updated":"2026-11-10 11:22:28.000000000","message":"I\u0027m not sure I like the fact that you pass a hostname instead of an AZ for the same parameter. Even if create can do something like --az :host:node it looks to me as a hack rather than a good way.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9a505d5514a805f6e0efbbe00de65839518cb428","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"A new API microversion will add an optional ``availability_zone`` parameter to"},{"line_number":57,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Users will be"},{"line_number":58,"context_line":"able to specify a zone, a host, or neither. The host and AZ fields will be"},{"line_number":59,"context_line":"mutually exclusive because a host already identifies its destination zone."},{"line_number":60,"context_line":"Host-only and untargeted scheduling behavior will remain unchanged."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"cc690439_8384d93e","line":58,"range":{"start_line":58,"start_character":23,"end_line":58,"end_character":31},"in_reply_to":"572e40af_e17c415b","updated":"2026-11-10 12:54:26.000000000","message":"it wont be the same parmater\n\nyou pas host in the host filed and az in the avialablity_zone parmater.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e7f48c29df077690176135f9b53c878f12124613","unresolved":false,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"A new API microversion will add an optional ``availability_zone`` parameter to"},{"line_number":57,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Users will be"},{"line_number":58,"context_line":"able to specify a zone, a host, or neither. The host and AZ fields will be"},{"line_number":59,"context_line":"mutually exclusive because a host already identifies its destination zone."},{"line_number":60,"context_line":"Host-only and untargeted scheduling behavior will remain unchanged."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"2c9b494a_426db718","line":58,"range":{"start_line":58,"start_character":23,"end_line":58,"end_character":31},"in_reply_to":"cc690439_8384d93e","updated":"2026-11-11 15:09:19.000000000","message":"Note that there are concrete examples of this below starting on line 190.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b0e495d49114b17c3d0e25b1b8efec64d39251d","unresolved":true,"context_lines":[{"line_number":57,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Users will be"},{"line_number":58,"context_line":"able to specify a zone, a host, or neither. The host and AZ fields will be"},{"line_number":59,"context_line":"mutually exclusive because a host already identifies its destination zone."},{"line_number":60,"context_line":"Host-only and untargeted scheduling behavior will remain unchanged."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"``RequestSpec.availability_zone`` records the AZ to which the server is"},{"line_number":63,"context_line":"pinned, reported as ``pinned_availability_zone``. It constrains scheduling;"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7be10c08_e7fbf70d","line":60,"updated":"2026-11-06 19:59:20.000000000","message":"I don\u0027t really understand why we would or should make them exclusive. If I want to migrate to a host and I want to make sure I\u0027m not picking the wrong one, why wouldn\u0027t you let me pass both and fail if they conflict? Meaning, if I have `host123235` and I think that one is free, but I _definitely_ need to make sure I don\u0027t push the instance out of the `us-east` AZ, passing both would allow me to state both intentions and let the computer refuse if I screwed up. I would think that if I\u0027m not an admin but a project-manager I might have visibility into some backend infrastructure but not _everything_. Staying in a (or targeting a) specific AZ is very much within my scope, but picking a host might be something I\u0027m guessing about or whatever because I don\u0027t have full visibility.\n\nTo put it another way, if I have an AZ pinned and and I pass host, I think I\u0027d expect a failure indicating the two requests (the previous AZ at boot/pin time) and the current migrate to host are in conflict. Why not make the behavior the same here? It makes it a consistent \"hey scheduler, request for $host and $az\" path in both cases, aside from the sanity-check benefit above.\n\nAside from the \"somewhat duplicative\" argument (which isn\u0027t wrong) is there some reason we should specifically forbid this?","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4dd3b9b250ad7792f7711b0f7492d212e7a01744","unresolved":true,"context_lines":[{"line_number":57,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Users will be"},{"line_number":58,"context_line":"able to specify a zone, a host, or neither. The host and AZ fields will be"},{"line_number":59,"context_line":"mutually exclusive because a host already identifies its destination zone."},{"line_number":60,"context_line":"Host-only and untargeted scheduling behavior will remain unchanged."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"``RequestSpec.availability_zone`` records the AZ to which the server is"},{"line_number":63,"context_line":"pinned, reported as ``pinned_availability_zone``. It constrains scheduling;"}],"source_content_type":"text/x-rst","patch_set":2,"id":"da01e7c4_b47bfaf1","line":60,"in_reply_to":"7be10c08_e7fbf70d","updated":"2026-11-09 13:35:41.000000000","message":"i dont have a strong prefence etiehr way, i slightly prefer the mutlally explisve group as the code is simpler and i think its less error prone to only specify 1 destiantion but your example of a \"self chack\" is not one i condiserd.\n\ni mainlay updated this to be a mutially excplvie group because stephen questioned\nwhy we would allow both to be passed and i did not have a good usecase to justify allowing both when it introduces another possible failure mode.\n\ni generally dont like second guessing our user but at least in the case wehre it is pinned we woudl have check the hsot is in the pinned az and that would still happen here.\n\nin the case its unpined form any az passign jsut the host shoudl be all that is requried to move between AZs as it is today. i can revert this back to accpeating both with the check fi that is what other prefer, that how i originally implemented in my first poc revisions","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e7f48c29df077690176135f9b53c878f12124613","unresolved":true,"context_lines":[{"line_number":57,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Users will be"},{"line_number":58,"context_line":"able to specify a zone, a host, or neither. The host and AZ fields will be"},{"line_number":59,"context_line":"mutually exclusive because a host already identifies its destination zone."},{"line_number":60,"context_line":"Host-only and untargeted scheduling behavior will remain unchanged."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"``RequestSpec.availability_zone`` records the AZ to which the server is"},{"line_number":63,"context_line":"pinned, reported as ``pinned_availability_zone``. It constrains scheduling;"}],"source_content_type":"text/x-rst","patch_set":2,"id":"f4cad291_6cdba290","line":60,"in_reply_to":"da01e7c4_b47bfaf1","updated":"2026-11-11 15:09:19.000000000","message":"@dms@danplanet.com Yeah, I asked for this change. Conceptually I considered host and AZ as separate types of \"destination\" for the live migration operation and thought the server-side check was unnecessary when this was so trivial to do client-side (it\u0027s not like TOCTOU is a serious concern). However, your note about create and unshelve behavior [below](https://review.opendev.org/c/openstack/nova-specs/+/1013094/comment/04350516_416568a6/) shows that we have prior art here: both allow you to specify both a host and an AZ, and it would be best to be consistent. I\u0027m okay to revert to allowing both here if Sean is.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5300f1476bccddfa1c508485b4e81008155951d1","unresolved":true,"context_lines":[{"line_number":57,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Users will be"},{"line_number":58,"context_line":"able to specify a zone, a host, or neither. The host and AZ fields will be"},{"line_number":59,"context_line":"mutually exclusive because a host already identifies its destination zone."},{"line_number":60,"context_line":"Host-only and untargeted scheduling behavior will remain unchanged."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"``RequestSpec.availability_zone`` records the AZ to which the server is"},{"line_number":63,"context_line":"pinned, reported as ``pinned_availability_zone``. It constrains scheduling;"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9fa6e509_1d232ed6","line":60,"in_reply_to":"f4cad291_6cdba290","updated":"2026-11-12 17:33:12.000000000","message":"Yeah, please let them to be expressed both, mostly because the operator can be wrong and we want to ensure that what he wants is correct.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d8e418d17983dcd8c227d38481a80d41a87f15b2","unresolved":true,"context_lines":[{"line_number":57,"context_line":"the ``migrate``, ``os-migrateLive``, and ``evacuate`` actions. Users will be"},{"line_number":58,"context_line":"able to specify a zone, a host, or neither. The host and AZ fields will be"},{"line_number":59,"context_line":"mutually exclusive because a host already identifies its destination zone."},{"line_number":60,"context_line":"Host-only and untargeted scheduling behavior will remain unchanged."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"``RequestSpec.availability_zone`` records the AZ to which the server is"},{"line_number":63,"context_line":"pinned, reported as ``pinned_availability_zone``. It constrains scheduling;"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4f1f497f_8df956bd","line":60,"in_reply_to":"f4cad291_6cdba290","updated":"2026-11-12 17:59:44.000000000","message":"to me expressing both create more room for operator error not less but we can revisit that in the future. we are choosing to expose a sharp knife rather then ensurign you cant express and invlaid combination in the api schema.\n\nwhat we can do is allow both for now, ill readd the check even ifthat is a bit more complex and we can decied fi we want to unif the shelve bevhiro and clean this up in a future microverion.\n\nits a bit more complex but i had it in v1 so its not hard to restore the check.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e7f48c29df077690176135f9b53c878f12124613","unresolved":false,"context_lines":[{"line_number":68,"context_line":"* If the requested destination AZ equals the AZ to which the server is"},{"line_number":69,"context_line":"  pinned, the operation will use the existing scheduling path for that server."},{"line_number":70,"context_line":"  This includes servers pinned to the default AZ. The new parameter will add"},{"line_number":71,"context_line":"  no constraint, and the API will not look up destination aggregates."},{"line_number":72,"context_line":"* If the server is pinned to an AZ and the requested destination AZ differs"},{"line_number":73,"context_line":"  from that AZ, the API will reject the request with HTTP 409. Moving across"},{"line_number":74,"context_line":"  AZs will require the user to unpin the server first using the existing"},{"line_number":75,"context_line":"  server update API."},{"line_number":76,"context_line":"* If the server is not pinned to an AZ, the API will add a per-request"},{"line_number":77,"context_line":"  destination constraint. The server will remain unpinned, including after"},{"line_number":78,"context_line":"  success."}],"source_content_type":"text/x-rst","patch_set":2,"id":"114e30c9_91a5a101","line":75,"range":{"start_line":71,"start_character":69,"end_line":75,"end_character":20},"updated":"2026-11-11 15:09:19.000000000","message":"I\u0027ve been thinking more on this. Do we want to keep insisting on this? At the moment you need to do:\n\n```\nopenstack server unset --pinned-availability-zone \u003cserver\u003e\nopenstack server migrate --live-migration --host \u003cdestination-host\u003e \u003cserver\u003e\n```\n\nor something like:\n\n```\nserver \u003d conn.compute.get_server(server_id)\nif server.pinned_availability_zone !\u003d host_az:\n    server \u003d conn.compute.update_server(pinned_availability_zone\u003dNone)\nconn.live_migrate_server(server, host\u003dhost)\n```\n\nIf we allow users to request both an AZ and host, as Dan originally suggested, why not allow the live migration operation to move the instance out of the AZ and into a new one. I\u0027d expect that that would result in a currently-pinned instance remaining pinned but in the new AZ. Operators could then simplify the above to:\n\n```\nopenstack server migrate --live-migration --host \u003cdestination-host\u003e \u003cserver\u003e\n```\n\nor:\n\n```\nconn.live_migrate_server(server, host\u003dhost)\n```\n\nI\u0027m guessing the biggest issue here is what we do if we encounter an error and rollback?\n\nLater: looks like Dan is asking the exact same question [below](https://review.opendev.org/c/openstack/nova-specs/+/1013094/comment/1971f72d_8ab18dda/). I\u0027m leaving this comment here but let\u0027s continue the conversation there.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6ddf27416877ae682142541f7164d3b8a0787ab1","unresolved":false,"context_lines":[{"line_number":72,"context_line":"* If the server is pinned to an AZ and the requested destination AZ differs"},{"line_number":73,"context_line":"  from that AZ, the API will reject the request with HTTP 409. Moving across"},{"line_number":74,"context_line":"  AZs will require the user to unpin the server first using the existing"},{"line_number":75,"context_line":"  server update API."},{"line_number":76,"context_line":"* If the server is not pinned to an AZ, the API will add a per-request"},{"line_number":77,"context_line":"  destination constraint. The server will remain unpinned, including after"},{"line_number":78,"context_line":"  success."}],"source_content_type":"text/x-rst","patch_set":2,"id":"f255f753_a7640d54","line":75,"updated":"2026-11-10 11:22:28.000000000","message":"LGTM.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5300f1476bccddfa1c508485b4e81008155951d1","unresolved":false,"context_lines":[{"line_number":68,"context_line":"* If the requested destination AZ equals the AZ to which the server is"},{"line_number":69,"context_line":"  pinned, the operation will use the existing scheduling path for that server."},{"line_number":70,"context_line":"  This includes servers pinned to the default AZ. The new parameter will add"},{"line_number":71,"context_line":"  no constraint, and the API will not look up destination aggregates."},{"line_number":72,"context_line":"* If the server is pinned to an AZ and the requested destination AZ differs"},{"line_number":73,"context_line":"  from that AZ, the API will reject the request with HTTP 409. Moving across"},{"line_number":74,"context_line":"  AZs will require the user to unpin the server first using the existing"},{"line_number":75,"context_line":"  server update API."},{"line_number":76,"context_line":"* If the server is not pinned to an AZ, the API will add a per-request"},{"line_number":77,"context_line":"  destination constraint. The server will remain unpinned, including after"},{"line_number":78,"context_line":"  success."}],"source_content_type":"text/x-rst","patch_set":2,"id":"e5587438_4777b1bf","line":75,"range":{"start_line":71,"start_character":69,"end_line":75,"end_character":20},"in_reply_to":"114e30c9_91a5a101","updated":"2026-11-12 17:33:12.000000000","message":"The only problem I see with automatic re-pinning is that sometimes it\u0027s difficult to know that the instance was pinned, particularly when you do boot-from-volume with a Cinder volume on a AZ and cross-az-attach be False.\nThere could be a situation where you end up with breaking that relationship if you start unpinning and pinning again to another AZ.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7455aaa24fac2e65ab88e038187d80648785805b","unresolved":true,"context_lines":[{"line_number":68,"context_line":"* If the requested destination AZ equals the AZ to which the server is"},{"line_number":69,"context_line":"  pinned, the operation will use the existing scheduling path for that server."},{"line_number":70,"context_line":"  This includes servers pinned to the default AZ. The new parameter will add"},{"line_number":71,"context_line":"  no constraint, and the API will not look up destination aggregates."},{"line_number":72,"context_line":"* If the server is pinned to an AZ and the requested destination AZ differs"},{"line_number":73,"context_line":"  from that AZ, the API will reject the request with HTTP 409. Moving across"},{"line_number":74,"context_line":"  AZs will require the user to unpin the server first using the existing"},{"line_number":75,"context_line":"  server update API."},{"line_number":76,"context_line":"* If the server is not pinned to an AZ, the API will add a per-request"},{"line_number":77,"context_line":"  destination constraint. The server will remain unpinned, including after"},{"line_number":78,"context_line":"  success."}],"source_content_type":"text/x-rst","patch_set":2,"id":"a0404afc_544bbca8","line":75,"range":{"start_line":71,"start_character":69,"end_line":75,"end_character":20},"in_reply_to":"cb6111fa_87dabf5e","updated":"2026-11-13 11:57:02.000000000","message":"note for unehelve we dont just pin on success we update the pin differently and if it erros we do nto restore it.\n\nwhile i prefer the idea that nova would update the pin for you the way that the palcement signslign works makes that trickier but no imposibale in the corss cell case as it basiclly ahs to be done in the final finalize step since it in the api db but in dans spec that step is async/lazy\n\nhttps://review.opendev.org/c/openstack/nova-specs/+/1008081/7/specs/2027.1/approved/cross-cell-live-migration.rst#268\n\ndan woudl have to rewite all the finaliastion process to not do it lazily to implement it\n\nwhich really woudl mean that we need the http internal event api or a long runing or pooling thread in the condurot or an upcall.\n\nthose are 3 things we put out of scope so this is out of scope fo this spec for a simialr reason.\n\nremember this spec exists to normalise the behvior between cold-migration, live-migration and evacute when changing AZ and that behvior has to constent if we are also changign cells. so the autopinning was dreicly put out of scope to not block the cross cell live migration spec.\n\nthis was orginally dicssed here\n\nhttps://review.opendev.org/c/openstack/nova-specs/+/1008081/comment/fefec958_023fe9c8/\n\n\nim not agasint addign the pinning behviro but i feel like to prevent scope creap given this spec was wrtinne around not doing that we shoudl adress that in a third spec for a diffent release unless we are ok with blocking both the cross cell and this spec until we arive at a design that work for both?\n\ni know dan also cited https://docs.openstack.org/nova/15.0.3/project_scope.html#no-more-orchestration\nas a reason not to do the auto pinning in \nhttps://review.opendev.org/c/openstack/nova-specs/+/1008081/comment/abf8947f_c922b43c/\n\nwhich again is one of the core reason this spec has this current shape and scope","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":true,"context_lines":[{"line_number":68,"context_line":"* If the requested destination AZ equals the AZ to which the server is"},{"line_number":69,"context_line":"  pinned, the operation will use the existing scheduling path for that server."},{"line_number":70,"context_line":"  This includes servers pinned to the default AZ. The new parameter will add"},{"line_number":71,"context_line":"  no constraint, and the API will not look up destination aggregates."},{"line_number":72,"context_line":"* If the server is pinned to an AZ and the requested destination AZ differs"},{"line_number":73,"context_line":"  from that AZ, the API will reject the request with HTTP 409. Moving across"},{"line_number":74,"context_line":"  AZs will require the user to unpin the server first using the existing"},{"line_number":75,"context_line":"  server update API."},{"line_number":76,"context_line":"* If the server is not pinned to an AZ, the API will add a per-request"},{"line_number":77,"context_line":"  destination constraint. The server will remain unpinned, including after"},{"line_number":78,"context_line":"  success."}],"source_content_type":"text/x-rst","patch_set":2,"id":"cb6111fa_87dabf5e","line":75,"range":{"start_line":71,"start_character":69,"end_line":75,"end_character":20},"in_reply_to":"e5587438_4777b1bf","updated":"2026-11-13 02:59:38.000000000","message":"I agree with Stephen that moving a server to AZ should unpin (if already pinned) and pin (on success) it also. That is what the first use case of AZ in the moving operation was, but the Nova internal pinning logic made it complex.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6ddf27416877ae682142541f7164d3b8a0787ab1","unresolved":false,"context_lines":[{"line_number":75,"context_line":"  server update API."},{"line_number":76,"context_line":"* If the server is not pinned to an AZ, the API will add a per-request"},{"line_number":77,"context_line":"  destination constraint. The server will remain unpinned, including after"},{"line_number":78,"context_line":"  success."},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"No case will require updating ``RequestSpec.availability_zone`` or restoring"},{"line_number":81,"context_line":"its value on failure or cold migration revert. This proposal will not change"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b6c634ce_adbbccd5","line":78,"updated":"2026-11-10 11:22:28.000000000","message":"LGTM too.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6ddf27416877ae682142541f7164d3b8a0787ab1","unresolved":false,"context_lines":[{"line_number":88,"context_line":"request spec\u0027s ``requested_destination`` object through"},{"line_number":89,"context_line":"``Destination.require_aggregates()``. A host in any aggregate defining the"},{"line_number":90,"context_line":"requested AZ will be eligible, subject to the server\u0027s other scheduling"},{"line_number":91,"context_line":"requirements."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"Hosts without an explicit AZ aggregate belong to the default availability"},{"line_number":94,"context_line":"zone configured by ``[DEFAULT]/default_availability_zone``. Requiring"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9f9e62e9_735d3a05","line":91,"updated":"2026-11-10 11:22:28.000000000","message":"++","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b0e495d49114b17c3d0e25b1b8efec64d39251d","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"04350516_416568a6","line":103,"updated":"2026-11-06 19:59:20.000000000","message":"I\u0027m really not sure about this. Especially since we have moved things like this to placement I\u0027m not sure that treating the default zone as something we can target makes sense.\n\nTo check, locally I have a five-node two-cell deployment. I put some of the nodes into a \"cell1\" AZ and left the others default:\n\n```\n$ oa compute service list -f value -c Binary -c host -c zone --service nova-compute | sort\nnova-compute noble1 nova\nnova-compute noble2 nova\nnova-compute noble3 nova\nnova-compute noble4 cell1\nnova-compute noble5 cell1\n```\n\nThen I booted something to the default zone:\n```\no --os-compute-api-version 2.100 server create --image cirros-0.6.3-x86_64-disk --flavor c1 test-az --nic net-id\u003dprivate --availability-zone nova\n```\n\nThat definitely thinks its \"pinned\" zone is `nova` but it landed on a host in the `cell1` AZ:\n\n```\n$ oa server show `osuuid test-az` -c pinned_availability_zone -c OS-EXT-AZ:availability_zone -c OS-EXT-SRV-ATTR:hypervisor_hostname\n+-------------------------------------+--------+\n| Field                               | Value  |\n+-------------------------------------+--------+\n| OS-EXT-AZ:availability_zone         | cell1  |\n| OS-EXT-SRV-ATTR:hypervisor_hostname | noble5 |\n| pinned_availability_zone            | nova   |\n+-------------------------------------+--------+\n```\n\nNow, that certainly sounds like a bug in create today. However I think we should be rejecting that and require all target operations to be to actually-defined AZs. Otherwise we always need to generate and pass the negative membership list to placement which doesn\u0027t seem sensical to me. Especially since the default zone is just a knob in the API\u0027s config. If I change it at runtime, I don\u0027t get any of the warnings we now provide about changing an instance-laden host\u0027s AZ and it just magically changes the output:\n```\n$ grep ^default_a /etc/nova/nova.conf\ndefault_availability_zone \u003d \u0027foobar\u0027\n$ oa compute service list -f value -c Binary -c host -c zone --service nova-compute | sort\nnova-compute noble1 foobar\nnova-compute noble2 foobar\nnova-compute noble3 foobar\nnova-compute noble4 cell1\nnova-compute noble5 cell1\n```\n\nYet even with the above change, our pin to the non-existent AZ remains what it used to be (which makes sense):\n```\n$ oa server show `osuuid test-az` -c pinned_availability_zone -c OS-EXT-AZ:availability_zone -c OS-EXT-SRV-ATTR:hypervisor_hostname\n+-------------------------------------+--------+\n| Field                               | Value  |\n+-------------------------------------+--------+\n| OS-EXT-AZ:availability_zone         | cell1  |\n| OS-EXT-SRV-ATTR:hypervisor_hostname | noble5 |\n| pinned_availability_zone            | nova   |\n+-------------------------------------+--------+\n```\nThat means it now looks like we\u0027ve asked for a pin to an AZ that doesn\u0027t exist, which is also (still) different from where we actually are:\n```\no availability zone list --compute\n+-----------+-------------+\n| Zone Name | Zone Status |\n+-----------+-------------+\n| cell1     | available   |\n| foobar    | available   |\n+-----------+-------------+\n```\n\nAFAICT, unshelve\u0027s AZ behavior behaves the same as create, FWIW. I haven\u0027t explored the impact of the above \"pinned to a different AZ than I\u0027m in and also not one that currently exists in the list\" instance for migrations, cinder `cross_az_attach` behavior, unshelve, etc.\n\n(later)\n\nAha, we actually document this as \"never do this thing\" explicitly:\n\nhttps://docs.openstack.org/nova/latest/admin/availability-zones.html\n\nIt says that users should never ask for it, and operators should never create an actual AZ named `nova`. It also kinda implies that it should never be changed (to avoid confusing over what the default is), and that the default should never be used \"in requests\".\n\nSo I definitely think that (a) migrate operations should exhibit the same AZ behavior as create and (b) that we should probably fix this across the board instead of just documenting it. The above situation where I ask for and am pinned to an AZ that is different from the one I am in is a pretty serious problem, IMHO. The docs say \"don\u0027t do it\" but it should be straightforward for us to make the API refuse such things to avoid the above obviously-wrong result. I definitely don\u0027t think we should bake that behavior into all the migration operations.\n\nIt\u0027s definitely a different spec, but I think I\u0027d argue that we should:\n1. Stop exposing unassigned hosts as being in the `default_availability_zone` and instead call them `unassigned` or something.\n2. Maybe stop exposing the `default_availability_zone` in the list of AZs when a user asks (I see no benefit to this behavior today)\n3. Stop allowing you to boot to a non-existent/implied AZ","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5b320e669e3fe7e89ec1e80f8d3e64ca6babb12","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b8c24af2_c7ebd665","line":103,"in_reply_to":"04155e25_bd730797","updated":"2026-11-11 15:29:47.000000000","message":"\u003e If we are going to ban use of the default AZ for create and move operations then IMO we also need to provide a way for users to discover what the default AZ is, e.g. via a change to `/os-availability-zone`.\n\nI don\u0027t understand this part. Why does a user need to know what \"the default AZ\" is? AFAICT, from the outside we have no current signaling of any such default. We have warnings not to assume that it\u0027s nova, but that\u0027s it I think. Today, choosing the default (if you know or guess, contrary to the docs) it is identical to passing nothing for AZ during a boot. To me, the only generic default is \"unspecified\", aside from some published default for a given deployment.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4dd3b9b250ad7792f7711b0f7492d212e7a01744","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7cdf5f14_2780b8e1","line":103,"in_reply_to":"04350516_416568a6","updated":"2026-11-09 13:35:41.000000000","message":"we do docuemnmt that, and i know that sever production clouds ignor that including psi, i also know that horizon by defualt pinned you to hte nova az out of the box.\n\nand i have had several converation over the years with oeprators that use the nova az as a real az either by naming a host aggrate key \"nova\" or using the implict one.\n\nthe reaons i was specifying it this way was to make sure we have a way to adress either a host aggreate that has the same name as the default az\n\nor the host that are in no az.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"3c7b801b70ad6c28bbb9ee4a2e4630ef5b55f14c","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4c1f4c85_573b3ab2","line":103,"in_reply_to":"071eaf7e_c253531a","updated":"2026-11-11 18:15:35.000000000","message":"Yep, noted in that review that it was just for the sake of being obvious for me to play with (and because the LLM is quite literal).\n\nEmpty string is the way to go so we don\u0027t need a microversion, unless people want to have empty string before and null after a microversion to make it nicer.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"6ddf27416877ae682142541f7164d3b8a0787ab1","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"73c3a447_50c6e457","line":103,"in_reply_to":"2ec02ef4_9e8dc538","updated":"2026-11-10 11:22:28.000000000","message":"honestly, no, please don\u0027t implement this : if a host isn\u0027t in a AZ, then any instances can go to it unless they are pinned to a specific AZ. As you said above, we would accept to migrate an instance to go to some AZ, so then it could arrive then, and I\u0027d rather fix this issue.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"82bf203fb1af5e0e8f280949d3f58976ae1908c0","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"70d39a0d_b824cccb","line":103,"in_reply_to":"3c1b732a_623f0e88","updated":"2026-11-11 16:32:19.000000000","message":"\u003e fwiw, I\u0027d also be okay with not returning the default AZ in this response, or at least not returning it in the non-detailed response (like the internal \"AZ\")\n\nAck, that\u0027s what I\u0027m proposing in my fix for the bug:\n\nhttps://review.opendev.org/c/openstack/nova/+/1014772","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5300f1476bccddfa1c508485b4e81008155951d1","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"de40806f_d5d8d02a","line":103,"in_reply_to":"4c1f4c85_573b3ab2","updated":"2026-11-12 17:33:12.000000000","message":"looks to me we have a consensus on the fact we should fix the problem by Dan\u0027s change and then remove that paragraph from the spec ? Am I correct ?","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"570842c3b892adaed7f4a35700a2c0525445aec7","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a3e79b9b_f409773d","line":103,"in_reply_to":"70d39a0d_b824cccb","updated":"2026-11-11 16:58:07.000000000","message":"Lovely. This works for me (I\u0027d seen the bug report but not the WIP fix)","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9a505d5514a805f6e0efbbe00de65839518cb428","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ea719c5e_35e99cb5","line":103,"in_reply_to":"73c3a447_50c6e457","updated":"2026-11-10 12:54:26.000000000","message":"to be clear the spcirifc issue i was addign this for is the edgecase where\nan admin creates a real az (host aggreate with metadata) named the same as the default AZ i.e. nova\n\nas dan noted in there bug report we report the default az `nova` jsut like any ohter so clinet doen know that its special. and since its configurabel you cant actully assuem an az called nova is the default az.\n\nso if you request nova for your migration destioantion we have 3 logical chocies\nwe can scuedule to the host not in any real az, we can schdule to the hosts in the explcitly named nova az, or we can schdule to the union of the two.\n\nto me schdulign too the union was the least surprisign so that what i did.\n\nif you explicitly request `nova` its not valid to schedule to `realAZ` and doign so would be a bug which is what https://bugs.launchpad.net/nova/+bug/2173771\ntracks.\n\nits posible to request noava and land on a host that is neither part of default az and is part of a differently named real az.\n\ndans solution to that is rejecting the request\nmine above was to actully do what the admin requested.\n\nif we go with dans approch it means we can never request to be schdule only to the host not in any az, which is fine we coudl not do that aready today based on the bug so there is no regression we will however be codefitying that explictly now.\n\nchatting to dan on irc i agree to remove this deail form the spec and just note the bug and say that this will be have the same as create.\n\nso if we \"fix\" create to also reject the default az then i will reject it as well for move ops, if we fix it to allow requesting the default az then the same will be true here.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c6882dfd895b83f80537b8db20ed70e1eb68a2a6","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ae13c69a_cf4130d5","line":103,"in_reply_to":"7cdf5f14_2780b8e1","updated":"2026-11-09 17:34:23.000000000","message":"If horizon is doing that, then we should definitely fix this for real as described above. I would expect all the instances it creates are pinned an an AZ that doesn\u0027t match the AZ of the host they land in, unless the operator is doing what we say not to do in our docs. Fixing it for real would both (a) help operators understand they should be assigning hosts properly according to the docs and (b) help drive change in horizon for that.\n\nI filed a bug for it:\n\nhttps://bugs.launchpad.net/nova/+bug/2173771","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"42551882ad8eab8b0992728a5398c28fc48b8c83","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"2ec02ef4_9e8dc538","line":103,"in_reply_to":"ae13c69a_cf4130d5","updated":"2026-11-09 18:29:52.000000000","message":"https://github.com/openstack/horizon/blob/a10860c5cfa573968d35594ac21337bcc1de5edc/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js#L368-L412\n\nthe basic behvior is of now az are reprot it skips the  value\nif exactly one is reqored it hardcodes that\notherwise it give you a multi select option dialog.\n\nif there are two or more az you can also defien \n\nmodel.default_availability_zone to select between a sentenal value \"Any\" which si traslated to the empty string adn a defautl for the dialog which is not nessiarly the saem as nova\u0027s default.\n\nthe horizon default seams to be any\n\nhttps://github.com/openstack/horizon/blob/a10860c5cfa573968d35594ac21337bcc1de5edc/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/launch-instance-model.service.js#L132\n\nbut i also knwo that there are two implation of some vies in horiszon that is the javscripti one and there is also a python/danjo one so i have no idea if the behvior is consitent.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"881d1948eae149db72a76b9b26a59c87a4fc3a7c","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3c1b732a_623f0e88","line":103,"in_reply_to":"b8c24af2_c7ebd665","updated":"2026-11-11 16:17:13.000000000","message":"Because of this:\n\n\u003e removing the ability to schedule to the default AZ would break users like CAPO. CAPO exposes failure domains (via `.status.failureDomains` on the `OpenStackCluster` CR) and it builds this array from Nova\u0027s `/os-availability-zone` API. iirc, this list will include nova (or whatever the default is) unless every single `nova-compute` host is in an explicit host aggregate with AZ metadata set\n\nConcretely, in your local reproducer you\u0027d see something like:\n\n```\nstatus:\n  failureDomains:\n    - name: nova\n      controlPlane: true\n    - name: cell1\n      controlPlane: true\n```\n\nWhich means if you create 4 control plane control plane `Machine`s, 2/4 will now be unschedulable instances if `\"availability_zone\": \"nova\"` if no longer be allowed). CAPO and others need some way to know \"this AZ is not a real AZ\" and shouldn\u0027t be reported and I don\u0027t think there\u0027s any way to do this currently?\n\nfwiw, I\u0027d also be okay with not returning the default AZ in this response, or at least not returning it in the non-detailed response (like the `internal` \"AZ\")","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d8e418d17983dcd8c227d38481a80d41a87f15b2","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"39772c3b_b64a4abf","line":103,"in_reply_to":"de40806f_d5d8d02a","updated":"2026-11-12 17:59:44.000000000","message":"i mean i would prefer to fix it by implemnted the logic above for create as well\ni think that woudl also be valid and less surpsing\n\nbu i think we have a path forward with dans propsoal too even if im not entrily conviced it a better ux it is at least more coneherent then the current state where we documetn dont do it(pin to implict az)  and know its commonly done even though its broken.\n\nso as i noted on irc ill remove this section shortly (before i finish today hopefully) and syplfy it to say we will mirror the behviro fo create, and we can decied what that shoudl be via dans change.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e7f48c29df077690176135f9b53c878f12124613","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"04155e25_bd730797","line":103,"in_reply_to":"ea719c5e_35e99cb5","updated":"2026-11-11 15:09:19.000000000","message":"Yeah, I\u0027d rather tackle this separately. I also think it needs a spec and microversion. The bug that Dan outlines is real, but removing the ability to schedule to the default AZ would break users like CAPO. CAPO exposes failure domains (via `.status.failureDomains` on the `OpenStackCluster` CR) and it builds tis array from Nova\u0027s `/os-availability-zone` API. iirc, this list will include `nova` (or whatever the default is) unless every single `nova-compute` host is in an explicit host aggregate with AZ metadata set. By default, control plane machines are automatically assigned a failure domain (in round-robin fashion) so it would be very likely that at least one machine would attempt to use `nova`. If we are going to ban use of the default AZ for create and move operations then IMO we also need to provide a way for users to discover what the default AZ is, e.g. via a change to `/os-availability-zone`.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"66fdeb86f58995f1a431aa0abd30c02f915705af","unresolved":true,"context_lines":[{"line_number":100,"context_line":"and hosts in explicit default-zone aggregates, while excluding hosts in other"},{"line_number":101,"context_line":"zones. If a server is pinned to the default AZ and requests that same AZ as"},{"line_number":102,"context_line":"its destination, the existing code path will be taken rather than adding"},{"line_number":103,"context_line":"these exclusions."},{"line_number":104,"context_line":""},{"line_number":105,"context_line":"The API will recognize a non-default destination AZ when aggregate metadata"},{"line_number":106,"context_line":"defines that zone, even if the aggregate has no hosts or all its hosts are"}],"source_content_type":"text/x-rst","patch_set":2,"id":"071eaf7e_c253531a","line":103,"in_reply_to":"ea719c5e_35e99cb5","updated":"2026-11-11 18:04:24.000000000","message":"ok i have reviewd your propsoed sollution in https://review.opendev.org/c/openstack/nova/+/1014772\n\nthat is a backward incomaptable api change that would require a spec and a microverion.\n\ni honestly think we shoudl not implement that, i expect it to break k8s and other services and we certenly can use `unassiged` as a new az value, we could use `\"\"` i.e. the empty string but we cant take waht was previosly a legal name and make it a sentirally withoug breaking anyone that used unassiged before as a pool of extra hardware that was not assigned to any tenant or project.\n\ni could totally see someone using an `unassigned` az with disabled hosts to store the extra chapascity they reserver for maintaince.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b0e495d49114b17c3d0e25b1b8efec64d39251d","unresolved":true,"context_lines":[{"line_number":131,"context_line":"Resize will not accept ``availability_zone``. Its request schema and existing"},{"line_number":132,"context_line":"scheduling behavior will remain unchanged. Although cold migration shares the"},{"line_number":133,"context_line":"internal resize path, this proposal will not expose AZ selection through the"},{"line_number":134,"context_line":"``resize`` action."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Alternatives"},{"line_number":137,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ff1b9631_ec15505a","line":134,"updated":"2026-11-06 19:59:20.000000000","message":"I\u0027m curious about the reasoning here. On the one hand, resize and cold migrate sharing a backend path is sort of a convenience for us. But on the other hand, I feel like we *do* consider resize a move operation, especially for clouds where they constrain flavors to run in specific areas. Resize is a user operation, so not accepting a host makes sense. However, `availability_zone` _is_ a user parameter, so it seems like it would make sense for them to be able to control it no?\n\nIn the case where my cloud does constrain flavors to specific areas, and my cloud uses AZs to let users pick class of hardware (which is very common since it\u0027s the only way users get to pick things), I may have to unpin to do the resize at all. If I do, then the next resize could move me from `us-west-class1` to `apac-class2`, which really what I want is `us-west-class2`. If I can unpin and then resize with the target AZ I actually want to stay in, then I won\u0027t have to get moved to another geo in the process.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5b320e669e3fe7e89ec1e80f8d3e64ca6babb12","unresolved":true,"context_lines":[{"line_number":131,"context_line":"Resize will not accept ``availability_zone``. Its request schema and existing"},{"line_number":132,"context_line":"scheduling behavior will remain unchanged. Although cold migration shares the"},{"line_number":133,"context_line":"internal resize path, this proposal will not expose AZ selection through the"},{"line_number":134,"context_line":"``resize`` action."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Alternatives"},{"line_number":137,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"b17a0824_f7a867ef","line":134,"in_reply_to":"1fb27ee7_f82a0e6e","updated":"2026-11-11 15:29:47.000000000","message":"My preference is that we add AZ to resize as well. I\u0027m not sure about host, maybe others can chime in. It feels like that\u0027s begging for people trying to force a resize to a host that can\u0027t take it because of scheduling restrictions, but that is no different than migration so I dunno. But AZ for sure, IMHO.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d8e418d17983dcd8c227d38481a80d41a87f15b2","unresolved":true,"context_lines":[{"line_number":131,"context_line":"Resize will not accept ``availability_zone``. Its request schema and existing"},{"line_number":132,"context_line":"scheduling behavior will remain unchanged. Although cold migration shares the"},{"line_number":133,"context_line":"internal resize path, this proposal will not expose AZ selection through the"},{"line_number":134,"context_line":"``resize`` action."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Alternatives"},{"line_number":137,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"2b7329b4_80221678","line":134,"in_reply_to":"3f62d644_43788323","updated":"2026-11-12 17:59:44.000000000","message":"i think we shoudl add neither or both\n\ni woudl prefer to aovid az only. the second we ad just the az an admin will ask wby can i cold migrate to a specic host but not resize to it.\n\nand internally this is the same code i am really just removing a check that stops us form passign them when its resize \n\nspecifcly this check \n\nhttps://review.opendev.org/c/openstack/nova/+/1013617/2/nova/compute/api.py#4306\n\nand then obviouly updating the api schema and tests to accpate the 2 field identially to cold migrate","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"66fdeb86f58995f1a431aa0abd30c02f915705af","unresolved":true,"context_lines":[{"line_number":131,"context_line":"Resize will not accept ``availability_zone``. Its request schema and existing"},{"line_number":132,"context_line":"scheduling behavior will remain unchanged. Although cold migration shares the"},{"line_number":133,"context_line":"internal resize path, this proposal will not expose AZ selection through the"},{"line_number":134,"context_line":"``resize`` action."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Alternatives"},{"line_number":137,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"bfcce87b_d6d6b9d8","line":134,"in_reply_to":"b17a0824_f7a867ef","updated":"2026-11-11 18:04:24.000000000","message":"i have no reall issue with doing that, i would prefer to add both again for partity since both woudl be supprot for cold migrate however since resize is aviabel to normal users i woudl keep the ablity to specify and host or az restircted to\n\n`PROJECT_MANAGER_OR_PROJECT_ADMIN` rather then just the normal member policy\nto keep it aligned to cold migrate.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5300f1476bccddfa1c508485b4e81008155951d1","unresolved":true,"context_lines":[{"line_number":131,"context_line":"Resize will not accept ``availability_zone``. Its request schema and existing"},{"line_number":132,"context_line":"scheduling behavior will remain unchanged. Although cold migration shares the"},{"line_number":133,"context_line":"internal resize path, this proposal will not expose AZ selection through the"},{"line_number":134,"context_line":"``resize`` action."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Alternatives"},{"line_number":137,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3f62d644_43788323","line":134,"in_reply_to":"bfcce87b_d6d6b9d8","updated":"2026-11-12 17:33:12.000000000","message":"I do believe we should add resize to AZ yes, as this can be an end-user ask. I\u0027m not opinionated whether we should add host parameter too (admin-only of course).","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4dd3b9b250ad7792f7711b0f7492d212e7a01744","unresolved":true,"context_lines":[{"line_number":131,"context_line":"Resize will not accept ``availability_zone``. Its request schema and existing"},{"line_number":132,"context_line":"scheduling behavior will remain unchanged. Although cold migration shares the"},{"line_number":133,"context_line":"internal resize path, this proposal will not expose AZ selection through the"},{"line_number":134,"context_line":"``resize`` action."},{"line_number":135,"context_line":""},{"line_number":136,"context_line":"Alternatives"},{"line_number":137,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1fb27ee7_f82a0e6e","line":134,"in_reply_to":"ff1b9631_ec15505a","updated":"2026-11-09 13:35:41.000000000","message":"so rebuild is never a move action where as evacuate that happens to share the same code alwasy is. those have alwasy felt clean cut.\n\ncold migrate is obvioulsy a move action but resize is od.\nby default it is alwasy a move as same host resize is disabled by default.\nyet we do not allow you to specify a host today\n\nso the only real reason i expclided it is we do not allow you to specify a destionat to day but if other agree im happy to just add host and az to bring it in line wiht cold migrate.\n\ni didnt have a specific usecase that needed that but i have not real objection to supproting it.\n\ni was just trying to contol scope. this really is a minal change as it jsut recire removing a single check in the code and then extra tests and docs.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b0e495d49114b17c3d0e25b1b8efec64d39251d","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1971f72d_8ab18dda","line":152,"updated":"2026-11-06 19:59:20.000000000","message":"I thought you argued at the PTG that you (or watcher) _wanted_ migration operations for pinned instances (with re-pin at the end). That\u0027s hard for live migration (in both cases) but it\u0027s not hard for cold migration (and thus resize) or evacuate. Shelve already does this (to the extent that it can) and you referenced it in that discussion as prior art.\n\nI assume the answer is \"to be consistent with live migration\", which I definitely appreciate, but: why not support migrating pinned instances when/where we can? And if we\u0027re going for consistency, why not make unshelve behave the same as the rest for consistency? Since there\u0027s already prior art for the move operations that _can_ support migrating pinned instances, could we consider making the \"colder\" operations keep that behavior? I know of at least one downstream request for migrating pinned instances in general. That\u0027s hard for live, but doable for the others I think, and as you noted, unshelve already does.\n\nDid you consider and reject this for some specific reason, or was it just consistency with live migration?","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4dd3b9b250ad7792f7711b0f7492d212e7a01744","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a658f07f_64411c77","line":152,"in_reply_to":"1971f72d_8ab18dda","updated":"2026-11-09 13:35:41.000000000","message":"i explicitly put this out of scope based on your feedback on the cross sell spec and your ptg comments.\n\ni wrote this spec to cover the watcher usecase and to factor out the az complexities form the live migration spec so i tried to keep it aligned to what i tought you and other would prefer based on those converstaions.\n\nbasically i wanted to draft the minimal set of changes that would enable the usecase\n\nwhile the orchestation would have been simpler i think on the watch side we are likely to proceed with not pinning the vms after we move them and have a policy for if we include pined vms or not in the candiates to move.\n\nwe certenly should not pin every vm we move btu the open is do we pin it if it was pined before or not and is that really a complexity we want to expose in our stragey input parmaters.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"badd1bd59cdc50dc6255dea45a22c22e63883980","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4649ef7e_174d2211","line":152,"in_reply_to":"206592af_023c2327","updated":"2026-11-13 15:19:33.000000000","message":"\u003e I was hoping to do the same in cross-cell live migration also (commented there), but due to the complexity of live migration, if we want to defer it for live migrations, then it is fine. \n\nYeah, we don\u0027t really have a way to make it happen for live migrations in general (new or old) because of how they complete async at the compute layer. We could take a similar lazy approach to restoring the pin in the RequestSpec once we read it and see that the instance has moved (or reverted) just like we do for the instance mapping. However, I\u0027d rather not do that for legacy live migration because we won\u0027t have the same \"are we sure it\u0027s done\" consistency.\n\n\u003e But if it\u0027s just me who thinks that both improvements (auto pinning/unpinning in moving operations except live moving) should go together, then I will not block at least the cross-AZ improvement.\n\nIt\u0027s not just you. I agree that migrating pinned instances where the pin is adjusted after completion is what most people want, and internally we have requests for it specifically. It\u0027s hard for live migration, but not for the others and that\u0027s why I said earlier I\u0027d rather if the colder operations do the pinning behavior we want and we can defer a solution for live migration. To me, consistency with what the end goal is wins over consistency with all the other operations. In other words less churn overall and fewer intermediate microversions where things don\u0027t behave the way we want, but we have to support that behavior forever. Plus, the only operation that supports this currently (unshelve) adjusts the pin.\n\n\u003e to be clear i dont think we should continue to supprot cross-az-attach\u003dFalse in the long term. i think having that be config driveen and an option that can vary per compute node was a mistake and we shoudl eb remvoign it\n\nWe can\u0027t remove it without an alternative because we (Red Hat) depend on it for some arrangements. The unpin operation may provide a workaround for those needs at this point, but I\u0027m not sure and would have to check. However, this is the first I\u0027m hearing of desire/need to remove it. Since not everyone lines up their AZs like that I\u0027m not sure how we could ever remove the ability to not enforce that.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"15ddf52b75302815a5ed0a34b8bc1ce5dcbcf898","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5c62d2df_50d53ac8","line":152,"in_reply_to":"4649ef7e_174d2211","updated":"2026-11-13 15:40:09.000000000","message":"i ment remvoe the ablity to set it to false\nie alwasy allow corss cell attach at the compute node level unconditioanlly\n\nthe way i  think tihs sould actully be done is with a pair fo filter and weither\nfor soft or hard affinity.\n\nthe operator woudl still choose if they wanted to require affinity or not by enabelign the filter/weigher and that gives us an optin to later encode this in the cinder voluem or volume type\n\nthe admin can already set a az requirem in a volume type, it woudl not be a large chagne to provide a flag on the volume type to allow expresisng the requriement compute az affinity \n\nthat woudl allow us to still express the requirement for affinity in an api discoveable way.\n\n\nunshilve changes the pin uncodtionally regardless of if the unshilve succeed, fi we want to match that behvior we can do that.\n\norginally this was tracked by \nhttps://bugs.launchpad.net/nova/+bug/1978573\nhttps://review.opendev.org/c/openstack/nova/+/911108\n\nwe discussed that at some lenght and agreed the curren tbehvior was intended\n\nit looks like rene has started to work on a related bug\nhttps://bugs.launchpad.net/nova/+bug/2132147 https://review.opendev.org/c/openstack/nova/+/984875\n\nmy issue with updating the az uncontionlly for livemigate is it coudl get out of sync on failure.\n\nif you revert or abort the mication form theapi we coudl fix it but we cant eaislly fix it in general without larger changes.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"877de87c8f272b1eec7bebdb6ac6daa267acc4c4","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"a6939d52_6d2089b2","line":152,"in_reply_to":"5c62d2df_50d53ac8","updated":"2026-11-13 16:33:50.000000000","message":"cross-az-attach is a different discussion; I was just saying that Sylvain\u0027s concern about cross-az-attach can be solved, as we already do for unshelve.\n\nComing back to the automatic pin/unpin scope, I am not sure when we made the rule that \"all migration operations need to be consistent for ALL improvements\". If so, it will make development harder, given the complexity of moving operations. I feel we should do it whenever and for all operations we can improve. \n\nI am not directly asking to extend the scope, but I am describing the expected use case for cross-AZ support by operators. Saying \u0027move my server to xyz AZ\u0027 should be a request from admin/manager to expect nova to handle the unpin and pin-on-success by itself instead of performing two more operations.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d8e418d17983dcd8c227d38481a80d41a87f15b2","unresolved":false,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"ed9868a0_82c8c99c","line":152,"in_reply_to":"71d96514_b9c8f504","updated":"2026-11-12 17:59:44.000000000","message":"If we were to do the automatic re-pinning we would have to do that in the cross cell change this cycle as well, so for now to limit the scope of both ill resolve this.\n\ni think we can add \"automatic az pinning\" to the lsit of things to revist for all move operation if we revisit the multaliy excplive group and shleve behavior in a future micro version.\n\nfor now this is workable if not ideal for us in watcher. we are discussing a pinning policy so the operator can decied if we never repin, alwasy repin or repin based on if the instnace was pinned before we moved it.\n\nif there is an error we will like do nothing and leave the vm unpinned to make it easier to fx as we cant really know where the vm is depending on how it error but the semaitcs are still being defied.\n\nim not discounting the cinder complexity but that woudl apply to live migrate as well, the auto pinnit we do for volumes and corss az attach only take effect durign create\n\nand we provided a way to unpin in the api which must take precednce over those config option already.\n\nso this spec does not need ot handel those edge case for the same reaosn the corss cell on does not.\n\nthey both only supprot moving instnaces across AZ if the instnace is not pinend to an AZ.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5300f1476bccddfa1c508485b4e81008155951d1","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"aee1e770_2c4685fd","line":152,"in_reply_to":"71d96514_b9c8f504","updated":"2026-11-12 17:33:12.000000000","message":"My main concern as noted earlier above is the cross-AZ-attachment with Cinder.\nThere are instances that are pinned automatically to an AZ if Cinder uses AZs too (and if some conf option is set) and I\u0027m afraid of the corner cases we may have if we go pin to another AZ which doesn\u0027t correlate to the volume AZ. I don\u0027t know how much this spec is taking care of those cases.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7455aaa24fac2e65ab88e038187d80648785805b","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"206592af_023c2327","line":152,"in_reply_to":"86a6f079_f6add339","updated":"2026-11-13 11:57:02.000000000","message":"to be clear i dont think we should continue to supprot cross-az-attach\u003dFalse in the long term. i think having that be config driveen and an option that can vary per compute node was a mistake and we shoudl eb remvoign it\n\n\nthis spec because of the scope it has drwan shoudn t not be impacted by this as we will only move instnafce that are not pinned to an az.\n\nnow if you want ot use this feature you basiclly cant set cross-az-attach\u003dFalse\nbut it defautl to true so that shoudl be fien i coudl however add a note that\ncoss az moves in general requirte all the guest storage to be accabel on the destionat.\n\nhttps://docs.openstack.org/nova/latest/configuration/config.html#cinder.cross_az_attach\n\nbasiclly are you askign me to add remvoign cross-az-attach in this spec? becuase i feel like that is the only path forward there and it probaly shoudl be its own spec not in this one.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5b320e669e3fe7e89ec1e80f8d3e64ca6babb12","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"71d96514_b9c8f504","line":152,"in_reply_to":"a658f07f_64411c77","updated":"2026-11-11 15:29:47.000000000","message":"Okay, I agree that\u0027s simpler I\u0027m just not sure it\u0027s what people are really going to want in most cases. Perhaps some others can opine about the UX.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":true,"context_lines":[{"line_number":149,"context_line":"A per-request destination avoids those persistent updates. Users can use"},{"line_number":150,"context_line":"the existing server update API to pin a server to its destination AZ after a"},{"line_number":151,"context_line":"successful move if required. A combined unpin-and-repin option is outside"},{"line_number":152,"context_line":"this proposal."},{"line_number":153,"context_line":""},{"line_number":154,"context_line":"A new ``Destination.availability_zone`` field could carry the AZ name to the"},{"line_number":155,"context_line":"scheduler. Resolving the name in the API will reuse the existing aggregate"}],"source_content_type":"text/x-rst","patch_set":2,"id":"86a6f079_f6add339","line":152,"in_reply_to":"ed9868a0_82c8c99c","updated":"2026-11-13 02:59:38.000000000","message":"AFAIK, the AZ use case in moving operations from one customer was to have the servers \"able to migrate across AZ,\" and one blocker for that was Nova pinning servers to an AZ.\n\nTo provide a workable way, Nova implemented the pin/unpin API to make \"able to migrate across AZ\" happen, but it\u0027s not a good design/UX. Users always have to perform two/three operations because of this pinning. Honestly, I thought we would get rid of (less recommended for users) using pin/unpin instead, and have move operations handle the pinning/unpinning internally when requested with the dest AZ.\n \nFor cinder volume cases, I think we can handle that:\n- if cross-az-attach\u003dTrue: no issue here\n- if cross-az-attach\u003dFalse: if the server-attached volume AZ conflicts with the requested AZ, then fail. We do the same for unshelve operation, if AZ in unshelve does not match with volume AZ then fail the request\n- https://github.com/openstack/nova/blob/af4419645e7507a68c0696a5f567e4841d53ad85/nova/compute/api.py#L4683\n\nI was hoping to do the same in cross-cell live migration also ([commented there]( https://review.opendev.org/c/openstack/nova-specs/+/1008081/comment/abf8947f_c922b43c/)), but due to the complexity of live migration, if we want to defer it for live migrations, then it is fine. But as we improve cold/resize/evacuate for AZ moves, we should improve the overall AZ experience for these operations. If not, I am sure users will complain (at least will not be comfortable) about having to do the pin/unpin dance before and after migrating servers across AZs. Basically: If users want to keep a server in AZ and migrate it as well, then they need to do:\n\n    - create server with pin AZ\n    - unpin AZ from server\n    - Migrate server to a different AZ\n    - Pin server to the migrated AZ\n\nvs\n\n    - create server with pin AZ\n    - Migrate server to a different AZ\n\nBut if it\u0027s just me who thinks that both improvements (auto pinning/unpinning in moving operations except live moving) should go together, then I will not block at least the cross-AZ improvement.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4b0e495d49114b17c3d0e25b1b8efec64d39251d","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"9e307394_e1fcb675","line":214,"updated":"2026-11-06 19:59:20.000000000","message":"Today, evacuate to a host that is not in the same cell as the instance will generate a synchronous failure to the API caller.\n\nSince we know we need to do cross-cell evacuate at some point soon and AZ is much more likely to be the way people handle such things this has me thinking... It was asserted at one point on the CCLM spec that the scheduler being able to select hosts in another cell might be a behavioral change worthy of a microversion bump if it affected the existing live migration op. In this case today a human or service has a positive and immediate \"no that won\u0027t work\" indication if they choose a host that isn\u0027t in the same cell (whether they know why or not). Once we put AZ in here, it becomes a `NoValidHost` later if the provided AZ is not in the same cell, and then presumably sometime in the future it will just start working. Point is, if we make this change today someone that is trying to move needs to probably interpret the `NoValidHost` as \"you picked an invalid AZ\" but in the future it would mean something different (that there\u0027s actually no capacity).\n\nI guess I\u0027m asking: from the watcher perspective does that mean we\u0027ll need a sort of empty microversion bump in the future to signal that shift in behavior or will we just reno it? If I had infinite time I think I\u0027d probably choose to couple cross-cell evacuation and the AZ add (much like in CCLM) but I know that\u0027s probably not preferred so I think it\u0027s worth at least deciding what the plan is here.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5f01475eedd39143d705a31119be37fd2712ef86","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"637b29e6_1666d7a7","line":214,"in_reply_to":"1c1658d6_352e6817","updated":"2026-11-12 00:14:04.000000000","message":"\u003e This isn\u0027t specific to evacuate and will be an issue for all move operations (note: not a reason to dismiss the issue but worth noting)\n\nThat\u0027s true, it just seems more important in the emergency case. I guess you could argue that adding AZs to each operation as we cross-cell-ify them would be better.\n\n\u003e Even when all operations do support cross-cell moves, the fact that you can disable this with policy (assuming we plan to use that model for all move operations) means the operator still needs to be aware of their configuration in order to distinguish between the \"this may have failed due to impossible constraints\" and \"this definitely indicates lack of capacity\" cases you noted.\n\nWe can disable it with policy but only asynchronously after we\u0027ve scheduled, so no immediate notification. Also, as we agreed in the CCLM spec, it would default to on (unlike cold migration) because live migration itself is admin-only. I would expect we\u0027d do the same for admin-only evacuation.\n\n\u003e I\u0027d expect an operator that cares about cells will know that they\u0027ve gained support to do $operation (evacuate here) in a cross-cell manner via an upgrade. Heck, it could be a reason to upgrade in the first place.\n\nThis is the communicating by reno I mentioned. It is certainly an option, it just seems like an unfortunate outcome of doing AZs first and then cells when we know we need to do both. It\u0027s also a signal that the client can\u0027t discover about the deployment, so it can\u0027t know which interpretation is right (without more info like logs as you say).\n\n\u003e I\u0027d also expect we\u0027ll put this behind policy again a la os_compute_api:servers:cross_cell_resize so they\u0027ll have to explicitly opt-in. Another signal for them.\n\nI think this is the same as your second bullet? If not I apologize for missing the distinction. But, there\u0027s no signal for users that are allowed. Getting a 403 (or as above, whatever async notification you\u0027d get about the policy difference) means you can\u0027t cross cells and thus the feature must be present, but it\u0027s irrelevant at that point since you can\u0027t do it. You can\u0027t tell the difference between being granted that ability (especially if by default) or being on a cloud from before the feature was present.\n\n\u003e The operator has access to scheduler logs.\n\nThe operator does, but the admin does not (necessarily). I\u0027m making the distinction between someone with API-only access and an admin token and someone who can ssh to the box and/or access backend log detail. We conflate those two a lot, but they\u0027re not necessarily the same and increasingly so lately.\n\nYou\u0027re not wrong, the logs will probably make it clear, but I personally don\u0027t want that to be the way to find out about something like this.\n\n\u003e This should be pretty helpful in understanding what\u0027s happened and to distinguish between the two scenarios (and if not, we probably want to address that separately)\n\nYeah but I mean, in our downstream product we have a tool that does the evacuates automatically and it definitely can\u0027t read the scheduler logs to know the difference. It\u0027s very not tied to nova version. Watcher won\u0027t have access to the logs either.\n\nAnyway, it\u0027s not extremely critical, I just think that it\u0027s unfortunate that we\u0027ll be opening this gap between when we add AZs and cross-cell support. Feels like we\u0027re probably not progressing here, and I think we\u0027ve moved from trying to understand my point to just arguing.\n\nI\u0027ll certainly support what the group consensus is here.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":7166,"name":"Sylvain Bauza","email":"sbauza@redhat.com","username":"sbauza"},"change_message_id":"5300f1476bccddfa1c508485b4e81008155951d1","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"97020ccb_18874205","line":214,"in_reply_to":"1cc66a35_8859a565","updated":"2026-11-12 17:33:12.000000000","message":"I got lost by the discussion but I do believe (and hope) we don\u0027t need a microversion once we add CC-evacuate as it will only be a capacity change for evacuation, not a behavioural change.\nFor example, we don\u0027t (oooof) add microversions every time we add a new scheduler filter.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c10c8ea2928aa3ef4001ec65b62934b1f6110d9f","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1c1658d6_352e6817","line":214,"in_reply_to":"20541371_e29ee064","updated":"2026-11-11 23:14:20.000000000","message":"Err, meant to reply quote to this section:\n\n\u003e If we give them [operators] AZs, they pick an AZ with lots of capacity and we say \"sorry there is no capacity there\" when really it\u0027s because we can\u0027t move them across cells. We can\u0027t reject it synchronously because we haven\u0027t yet asked the scheduler which host, and thus we don\u0027t know that it\u0027s in a different cell until later. In my experience, any time they pick a destination with lots of capacity and we tell them \"no capacity\" they file a bug or open a support case.\n\nLet\u0027s all pretend I did that...","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"060ec2b37969ee551e6b30975c64b723a51a4b29","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"20541371_e29ee064","line":214,"in_reply_to":"319381ec_543bc539","updated":"2026-11-11 23:12:11.000000000","message":"\u003e But, unprivileged users can\u0027t do evacuate and wouldn\u0027t open a support case for \"I know this AZ is empty, nova allowed the evacuate operation, but keeps complaining that there\u0027s no capacity there.\"\n\nI\u0027m not sure about this for a few reasons:\n\n* This isn\u0027t specific to evacuate and will be an issue for all move operations (note: not a reason to dismiss the issue but worth noting)\n* Even when all operations do support cross-cell moves, the fact that you can disable this with policy (assuming we plan to use that model for all move operations) means the operator still needs to be aware of their configuration in order to distinguish between the \"this may have failed due to impossible constraints\" and \"this definitely indicates lack of capacity\" cases you noted.\n* I\u0027d expect an operator that cares about cells will know that they\u0027ve gained support to do $operation (evacuate here) in a cross-cell manner via an upgrade. Heck, it could be a reason *to* upgrade in the first place.\n* I\u0027d also expect we\u0027ll put this behind policy again a la `os_compute_api:servers:cross_cell_resize` so they\u0027ll have to explicitly opt-in. Another signal for them.\n* The operator has access to scheduler logs. This should be pretty helpful in understanding what\u0027s happened and to distinguish between the two scenarios (and if not, we probably want to address that separately)","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e7f48c29df077690176135f9b53c878f12124613","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"96bf8601_6b84fb44","line":214,"in_reply_to":"4fc1fc5c_cc1dc19a","updated":"2026-11-11 15:09:19.000000000","message":"I know this was directed at Sean and Watcher, but from a SDK/OSC/gophercloud perspective, I would be heavily in favour of a signalling microversion here. It\u0027s effectively free (we stick the cross-cell check under an if conditional) but gives us a guaranteed way to know $thing is supported","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"fd4a24e7501e4a73b4946e6ef6afcf34f7034fe3","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1cc66a35_8859a565","line":214,"in_reply_to":"637b29e6_1666d7a7","updated":"2026-11-12 10:43:04.000000000","message":"\u003e Anyway, it\u0027s not extremely critical, I just think that it\u0027s unfortunate that we\u0027ll be opening this gap between when we add AZs and cross-cell support. Feels like we\u0027re probably not progressing here, and I think we\u0027ve moved from trying to understand my point to just arguing.\n\nOh, I personally think this has been useful to figure out your concerns. I understand them better now, even if I don\u0027t necessarily agree. Just fwiw.\n\n\u003e I\u0027ll certainly support what the group consensus is here.\n\nDitto.\n\nOn this point:\n\n\u003e I think this is the same as your second bullet? If not I apologize for missing the distinction. But, there\u0027s no signal for users that are allowed.\n\nSimilar but different. Second point noted that the policy knob means we\u0027re still open to the \"\"sorry there is no capacity there\" when really it\u0027s because we can\u0027t move them across cells\" issue highlighted here. Fourth point noted that the operator had to configure policy so they would have a (non-reno) signal that something had changed (that ones not valid if we default the policy to on). Sorry that the distinction wasn\u0027t clear.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5b320e669e3fe7e89ec1e80f8d3e64ca6babb12","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"d4508a0b_512bd65c","line":214,"in_reply_to":"96bf8601_6b84fb44","updated":"2026-11-11 15:29:47.000000000","message":"Just to be clear: you mean a signaling microversion for the case where evacuate starts supporting cross-cell evacuations? If so, that\u0027s why I asked the question because I definitely to _not_ want that behavior. So far we\u0027ve managed to avoid leaking the details of cells out of the API (an original tenet of cellsv2). Even when we added the first ability to migrate across cells, we kept it entirely internal and specifically say in our docs that no microversion change is made:\n\nhttps://docs.openstack.org/nova/latest/admin/configuration/cross-cell-resize.html#policy-configuration\n\nI think the problem here is that we\u0027ll be subtly changing the meaning of a NoValidHost if we implement AZs for evacuate and then later go back and add the cross-cell bit. For someone (or something) that is trying to rebuild in an emergency, the difference there is pretty meaningful.\n\nPerhaps we could slice off evacuate from this list and handle AZs for it separately with the planned cross-cell work (which would likely mean next cycle)?","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d8e418d17983dcd8c227d38481a80d41a87f15b2","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"2c79e30b_3379e386","line":214,"in_reply_to":"97020ccb_18874205","updated":"2026-11-12 17:59:44.000000000","message":"i think we have converged on no microversion is requried to signal cross cell capablity for any move operation. a microversion can be intoduced if there is another reason to have one but supproting corss cell is by itself not enugh to require one.  if we decied to have a serpeate api action for a new implemtiont of evacute or shleve that woudl requrie a micoverion but we can dicuss that when we work on the cell feature.\n\ni dont think it would be correct to couple cross az evacuate and cross cell evacuate for the saem reason i dont think its correct to include the az i cross cell live migrate spec.we really shoudl not be dicssing cells in this spec as they are explcity out of scope.\n\nwe certelly dont want to use the fact you can ask for an az as a signal that a cloud suprpots cross cell. any clinet that depended on the az parameter to make that choose woudl be wrong. even a microversion would not tell you if a cloud has the netwrok connectivity or storage reachablity to enable the move.\n\nso whter nova supprot it and the deployment supprot it are two entirly diffen quetsions.\n\ni think we can resovle this thread but ill leave it open until i have pushed the new revsision.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4dd3b9b250ad7792f7711b0f7492d212e7a01744","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"4fc1fc5c_cc1dc19a","line":214,"in_reply_to":"9e307394_e1fcb675","updated":"2026-11-09 13:35:41.000000000","message":"we can always resive a 400 or 409 (locked) when we execute a plan.\nwhetere it a syncones error or asyc is effectivly the same form a watcher perspective we will not need to have a microversion.\n\nwatcher works in 2 phases, audit to produce an action plan and execuation of an appoved action plan.\n\nthe applier does not really get to make any desicosn at execution time beyond skipping an action due to a preconditon check such as the isntance was deleted or already moved out of band to the intneded destiontioin.\nif any action in the agreed plan failes i.e. because we get a NoValidHost or a synconous error for crosss cell the action is recoreded as failed and we have a \"status_message\" field where we can optional populate a status message which is effeictlvy the reaosn it failed similar to nova fault field but we also use it for the skipped resaons hence the diffent name\n\ni think all that woudl change is perhasp the content of the status message but we dont currently store the exact reason in it on failure today.\n\nwatcher currently has no cell awareness so today if you use it in a multi cell deployment the operator has to use the audit scope parmaters to restict the audit to a single cell at a time for correct operations.\n\nas such we do not offically supprot multi cell audits in watcher today, you can make it work but we have no testing, docutmation ro expiclty supprot for that.\n\nwe do hoave supprot host aggrates and comptue nodes as scoping mechanisums.\n\ni.e. draind a given compute node or blance workload within a host aggreate.\n\nso if you happen to align a host aggrate to a cell that as closs as you can get today to makeing water work with cells.\n\nso to answer your questin i dont think supprot cross cell evacuation or not would matially have an impact on watcher even if the eror chagned form async to sync or vice versa.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"97c4ada13d1e03e6d40d018393689f915d74c4b4","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"319381ec_543bc539","line":214,"in_reply_to":"aadb0d9c_11f0e842","updated":"2026-11-11 18:05:23.000000000","message":"\u003e However, AZs don\u0027t belong to cells or vice versa: hosts do. Therefore while it makes sense to have a synchronous check for a potential cross-cell move when requesting a host, I don\u0027t think we\u0027d ever expect/want to do something like this for AZs. As far as I\u0027m concerned, our possible flavours of \"we can\u0027t satisfy your AZ request\" error possible here are:\n\u003e \n\u003e 1. User requested an AZ that doesn\u0027t exist\n\u003e 2. User requested an AZ but all its hosts are full\n\u003e 3. User requested an AZ but all its hosts are in a different cell\n\nNo, you\u0027ve got it right, except that 2 and 3 are reversed if we do what this spec says first and add cross-cell evacuation later. The thing I see as a problem is maybe more relevant to who is doing this, and under what circumstances. So, a regular user sees none of the backend of this and so NoValidHost means nothing more than \"we have nowhere to put this based on what you asked for\" and they can\u0027t really argue about it because we wouldn\u0027t even tell them details like hostnames, much less cells.\n\nBut, evacuate is an admin operation, run at emergency time and often with a lot of backend knowledge. Meaning, the admin is (or their scripts are) trying to quickly find places for everything to go, often with strong opinions about where, and thus specifying a host. If we give them AZs, they pick an AZ with lots of capacity and we say \"sorry there is no capacity there\" when really it\u0027s because we can\u0027t move them across cells. We can\u0027t reject it synchronously because we haven\u0027t yet asked the scheduler which host, and thus we don\u0027t know that it\u0027s in a different cell until later. In my experience, any time they pick a destination with lots of capacity and we tell them \"no capacity\" they file a bug or open a support case.\n\nSo, that\u0027s confusing but we could justify it because evacuates are generally admin-only and we could say \"but the admin should have known\" that NoValidHost might be signaling to them that they picked an impossible destination with plenty of capacity. We could document this as \"also be aware of this, please don\u0027t call.\"\n\nHowever, _after_ we change evacuate to support crossing cells, the indication means something different: that there\u0027s actually no capacity there. If the admin knows differently, then a bug or support case probably _is_ warranted. We can signal it in a reno, but that\u0027s not a very strong signal.\n\n\u003e We can/should handle 1 synchronously. You\u0027re suggesting (???) that we would also want to treat 2 and 3 as distinct things but I think they\u0027re effectively identical (they both signal there isn\u0027t a *host* available to move to: the reason for why is irrelevant from an API context).\n\nFrom the view of an unprivileged user 2 and 3 are indistinguishable for sure. But, unprivileged users can\u0027t do evacuate and wouldn\u0027t open a support case for \"I _know_ this AZ is empty, nova allowed the evacuate operation, but keeps complaining that there\u0027s no capacity there.\"\n\nWe totally can conflate 2 and 3, I just prefer that we not, that\u0027s all :)","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"66fdeb86f58995f1a431aa0abd30c02f915705af","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"f3a01641_f2e35632","line":214,"in_reply_to":"aadb0d9c_11f0e842","updated":"2026-11-11 18:04:24.000000000","message":"i dont think we need a sginaling migration for cross cell for any operations inclduign evacuate.\n\nwe coudl add one but i dont think we should have one for live migratre either, we did not for cold migrate.\n\ncells are intenreal and liftign the internal restrction on cross cell operatiosn should not require a micoversion change at all from my perspective.\n\nwe only added behvioral mivroversion for BFV rebuild because it was distructive\nto the data.\n\ni dont think a microversion is free becuase if we have one we must block cross cell opetions for loder micrversion which again is not in line with cross cell cold migration.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8307d44f8b9a9c1f5598e04fc1f9cd635f75931a","unresolved":true,"context_lines":[{"line_number":211,"context_line":"        \"evacuate\": {"},{"line_number":212,"context_line":"            \"availability_zone\": \"zone2\""},{"line_number":213,"context_line":"        }"},{"line_number":214,"context_line":"    }"},{"line_number":215,"context_line":""},{"line_number":216,"context_line":"Cold and live migration return HTTP 202 with an empty response body when"},{"line_number":217,"context_line":"accepted. Evacuation is also asynchronous but returns HTTP 200. Starting with"}],"source_content_type":"text/x-rst","patch_set":2,"id":"aadb0d9c_11f0e842","line":214,"in_reply_to":"d4508a0b_512bd65c","updated":"2026-11-11 16:55:37.000000000","message":"\u003e So far we\u0027ve managed to avoid leaking the details of cells out of the API (an original tenet of cellsv2).\n\nOkay, that\u0027s fair. I strongly prefer being able to discover as much as possible from the API, but yes, v2 cells are not an API-visible thing and we shouldn\u0027t do that here.\n\n\u003e I think the problem here is that we\u0027ll be subtly changing the meaning of a NoValidHost if we implement AZs for evacuate and then later go back and add the cross-cell bit. For someone (or something) that is trying to rebuild in an emergency, the difference there is pretty meaningful.\n\nI don\u0027t think I understand the issue here, so forgive me if I\u0027ve got the wrong end of the stick. However, AZs don\u0027t belong to cells or vice versa: hosts do. Therefore while it makes sense to have a synchronous check for a potential cross-cell move when requesting a host, I don\u0027t think we\u0027d ever expect/want to do something like this for AZs. As far as I\u0027m concerned, our possible flavours of \"we can\u0027t satisfy your AZ request\" error possible here are:\n\n1. User requested an AZ that doesn\u0027t exist\n2. User requested an AZ but all its hosts are full\n3. User requested an AZ but all its hosts are in a different cell\n\nWe can/should handle 1 synchronously. You\u0027re suggesting (???) that we would also want to treat 2 and 3 as distinct things but I think they\u0027re effectively identical (they both signal there isn\u0027t a *host* available to move to: the reason for why is irrelevant from an API context).\n\nWhat am I missing? 😅","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"e7f48c29df077690176135f9b53c878f12124613","unresolved":true,"context_lines":[{"line_number":250,"context_line":"Evacuation will continue to use ``os_compute_api:os-evacuate``, which defaults"},{"line_number":251,"context_line":"to admin-only access. No additional policy will be introduced for AZ-targeted"},{"line_number":252,"context_line":"evacuation."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Security impact"},{"line_number":255,"context_line":"---------------"},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"e7b1d682_dc46f3da","line":253,"updated":"2026-11-11 15:09:19.000000000","message":"I have one more ask spanning from the [\"do we allow both AZ and host\" discussion above](https://review.opendev.org/c/openstack/nova-specs/+/1013094/comment/7be10c08_e7fbf70d/): could we start returning a synchronous HTTP 409 (Conflict) on `POST /servers` if host.az !\u003d requested az, rather than waiting for No Valid Host as I believe we do currently. This would align behavior of this API with the move operations here.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":true,"context_lines":[{"line_number":250,"context_line":"Evacuation will continue to use ``os_compute_api:os-evacuate``, which defaults"},{"line_number":251,"context_line":"to admin-only access. No additional policy will be introduced for AZ-targeted"},{"line_number":252,"context_line":"evacuation."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Security impact"},{"line_number":255,"context_line":"---------------"},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"586ac191_cd155529","line":253,"in_reply_to":"28acbb09_3a21b268","updated":"2026-11-13 02:59:38.000000000","message":"I feel 400 makes more sense here, since the request has two things that don\u0027t match and could cause the request to fail, so it\u0027s a request problem. Keeping it consistent with 400 will make sense (if we want to change the unshelve case also at some point).","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"82bf203fb1af5e0e8f280949d3f58976ae1908c0","unresolved":true,"context_lines":[{"line_number":250,"context_line":"Evacuation will continue to use ``os_compute_api:os-evacuate``, which defaults"},{"line_number":251,"context_line":"to admin-only access. No additional policy will be introduced for AZ-targeted"},{"line_number":252,"context_line":"evacuation."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Security impact"},{"line_number":255,"context_line":"---------------"},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7e376c4a_3f10b2dd","line":253,"in_reply_to":"45bbc386_a0e06225","updated":"2026-11-11 16:32:19.000000000","message":"\u003e \u003e But yes, synchronous would be good and it\u0027s what I\u0027m already doing in CCLM.\n\u003e \n\u003e Just to be clear, you know I\u0027m talking about _create_ (`POST /servers`) here, yeah? I ask because I didn\u0027t think you were touching that in [the CCLM change currently](https://review.opendev.org/c/openstack/nova/+/1008839/)? Have I missed a patch? 😅\n\nI did but I was extending that to basically \"all places where we take a host and AZ, do a synchronous check and return the same error code.\" All I was saying about CCLM was that I like this behavior and (code aside) I am in line with that in the current proposal. When I said \"for this\" I meant \"for this scenario, where some action is asking for host+az and they don\u0027t match\", but I see why that was confusing :)\n\n\u003e As for why HTTP 409 (Conflict), I suggested that because that\u0027s what unshelve does currently and it\u0027s what Sean is suggesting for live migrate here (grep for 409). Sounds like we probably want agreement here and should either change unshelve to use 400 or be consistent and use 409 everywhere.\n\nYeah, I\u0027m not overly concerned with the actual code. To me 409 applies when the entity\u0027s current state is not compatible with what you\u0027re asking for in the new request. I suppose this is most important to signal a TOCTOU problem where you thought it was in a good state and something else has since changed it. The spec said that 409 would only be if the state was in conflict (which makes sense):\n\nhttps://specs.openstack.org/openstack//nova-specs/specs/zed/implemented/unshelve-to-host.html\n\nHowever, the code sort of conflates the current pin (if present) and the proposed pin (if provided) and then returns 409 if the _new_ AZ (`effective_az_after_unshelve` in the code) is going to be in conflict with the host provided. To me that\u0027s probably not exactly right for a 409 and is like that just because of brevity in the implementation.\n\nBut, if we want to just pick 409 because of brevity and/or prior art, that\u0027s fine with me.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"881d1948eae149db72a76b9b26a59c87a4fc3a7c","unresolved":true,"context_lines":[{"line_number":250,"context_line":"Evacuation will continue to use ``os_compute_api:os-evacuate``, which defaults"},{"line_number":251,"context_line":"to admin-only access. No additional policy will be introduced for AZ-targeted"},{"line_number":252,"context_line":"evacuation."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Security impact"},{"line_number":255,"context_line":"---------------"},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"45bbc386_a0e06225","line":253,"in_reply_to":"481b24f7_cbcdf662","updated":"2026-11-11 16:17:13.000000000","message":"\u003e But yes, synchronous would be good and it\u0027s what I\u0027m already doing in CCLM.\n\nJust to be clear, you know I\u0027m talking about _create_ (`POST /servers`) here, yeah? I ask because I didn\u0027t think you were touching that in [the CCLM change currently](https://review.opendev.org/c/openstack/nova/+/1008839/)? Have I missed a patch? 😅\n\nAs for why HTTP 409 (Conflict), I suggested that because that\u0027s what unshelve does currently and it\u0027s what Sean is suggesting for live migrate here (grep for 409). Sounds like we probably want agreement here and should either change unshelve to use 400 or be consistent and use 409 everywhere.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"570842c3b892adaed7f4a35700a2c0525445aec7","unresolved":true,"context_lines":[{"line_number":250,"context_line":"Evacuation will continue to use ``os_compute_api:os-evacuate``, which defaults"},{"line_number":251,"context_line":"to admin-only access. No additional policy will be introduced for AZ-targeted"},{"line_number":252,"context_line":"evacuation."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Security impact"},{"line_number":255,"context_line":"---------------"},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"28acbb09_3a21b268","line":253,"in_reply_to":"7e376c4a_3f10b2dd","updated":"2026-11-11 16:58:07.000000000","message":"\u003e \u003e \u003e But yes, synchronous would be good and it\u0027s what I\u0027m already doing in CCLM.\n\u003e \u003e \n\u003e \u003e Just to be clear, you know I\u0027m talking about _create_ (`POST /servers`) here, yeah? I ask because I didn\u0027t think you were touching that in [the CCLM change currently](https://review.opendev.org/c/openstack/nova/+/1008839/)? Have I missed a patch? 😅\n\u003e \n\u003e I did but I was extending that to basically \"all places where we take a host and AZ, do a synchronous check and return the same error code.\" All I was saying about CCLM was that I like this behavior and (code aside) I am in line with that in the current proposal. When I said \"for this\" I meant \"for this scenario, where some action is asking for host+az and they don\u0027t match\", but I see why that was confusing :)\n\nGreat \\o/\n\n\u003e \u003e As for why HTTP 409 (Conflict), I suggested that because that\u0027s what unshelve does currently and it\u0027s what Sean is suggesting for live migrate here (grep for 409). Sounds like we probably want agreement here and should either change unshelve to use 400 or be consistent and use 409 everywhere.\n\u003e \n\u003e Yeah, I\u0027m not overly concerned with the actual code. To me 409 applies when the entity\u0027s current state is not compatible with what you\u0027re asking for in the new request. I suppose this is most important to signal a TOCTOU problem where you thought it was in a good state and something else has since changed it. The spec said that 409 would only be if the state was in conflict (which makes sense):\n\u003e \n\u003e https://specs.openstack.org/openstack//nova-specs/specs/zed/implemented/unshelve-to-host.html\n\u003e \n\u003e However, the code sort of conflates the current pin (if present) and the proposed pin (if provided) and then returns 409 if the _new_ AZ (`effective_az_after_unshelve` in the code) is going to be in conflict with the host provided. To me that\u0027s probably not exactly right for a 409 and is like that just because of brevity in the implementation.\n\u003e \n\u003e But, if we want to just pick 409 because of brevity and/or prior art, that\u0027s fine with me.\n\nAck. Personally, I\u0027m happy with both 400 or 409. I\u0027d just like us to use the same thing everywhere.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"d5b320e669e3fe7e89ec1e80f8d3e64ca6babb12","unresolved":true,"context_lines":[{"line_number":250,"context_line":"Evacuation will continue to use ``os_compute_api:os-evacuate``, which defaults"},{"line_number":251,"context_line":"to admin-only access. No additional policy will be introduced for AZ-targeted"},{"line_number":252,"context_line":"evacuation."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Security impact"},{"line_number":255,"context_line":"---------------"},{"line_number":256,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"481b24f7_cbcdf662","line":253,"in_reply_to":"e7b1d682_dc46f3da","updated":"2026-11-11 15:29:47.000000000","message":"I think we identified in the CCLM spec that we want 400 for this (because it\u0027s a problem with what you\u0027re asking, not the state of the entity you\u0027re asking about). But yes, synchronous would be good and it\u0027s what I\u0027m already doing in CCLM.","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"9ddb369b312913abb6b59566fef2104b2de21239","unresolved":true,"context_lines":[{"line_number":341,"context_line":"* Add AZ-aware move tests in Tempest, with source and destination AZ"},{"line_number":342,"context_line":"  configuration options mirroring ``migration_source_host`` and"},{"line_number":343,"context_line":"  ``migration_dest_host``."},{"line_number":344,"context_line":"* Add OpenStackSDK and python-openstackclient support in separate changes."},{"line_number":345,"context_line":""},{"line_number":346,"context_line":"Dependencies"},{"line_number":347,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":2,"id":"54e144c1_be709257","line":344,"range":{"start_line":344,"start_character":1,"end_line":344,"end_character":74},"updated":"2026-11-04 03:10:16.000000000","message":"i still need to do the osc change but i have a draft of the sdk changes including a new job usign the nova fake driver to test the mover opertions via a functional sdk devstack job.\n\nhttps://review.opendev.org/c/openstack/openstacksdk/+/1014008\nhttps://review.opendev.org/c/openstack/openstacksdk/+/1014009\n\nhttps://b144e1a425f64dfc6773-600fece9b6b15288557668781b791ebc.ssl.cf5.rackcdn.com/openstack/15954f63cdf44b4586dc9701eec515f8/testr_results.html","commit_id":"5c1070842c85298bc69a08995c4a34957119e779"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":false,"context_lines":[{"line_number":73,"context_line":"  pinned, the operation will use the existing scheduling path for that server."},{"line_number":74,"context_line":"  The new parameter will add no constraint, and the API will not look up"},{"line_number":75,"context_line":"  destination aggregates."},{"line_number":76,"context_line":"* If the server is pinned to an AZ and the requested destination AZ differs"},{"line_number":77,"context_line":"  from that AZ, the API will reject the request with HTTP 409. Moving across"},{"line_number":78,"context_line":"  AZs will require the user to unpin the server first using the existing"},{"line_number":79,"context_line":"  server update API."},{"line_number":80,"context_line":"* If the server is not pinned to an AZ, the API will add a per-request"},{"line_number":81,"context_line":"  destination constraint. The server will remain unpinned, including after"},{"line_number":82,"context_line":"  success."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"No case will require updating ``RequestSpec.availability_zone`` or restoring"},{"line_number":85,"context_line":"its value on failure or cold migration or resize revert. This proposal will"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e16971dc_e32bc114","line":82,"range":{"start_line":76,"start_character":0,"end_line":82,"end_character":10},"updated":"2026-11-13 02:59:38.000000000","message":"I feel we should allow them and let pin/unpin happen as per the requested AZ during the moving operation. I replied on the previous comment where it was discussed but this was the ask in cross cell migration spec also but at least we should do it in other migration operations except live moving.\n\nI am marking it resolve here so that we can continue the discussion in main comment thread.","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":false,"context_lines":[{"line_number":213,"context_line":"    }"},{"line_number":214,"context_line":""},{"line_number":215,"context_line":"Cold migration, resize, and live migration return HTTP 202 with an empty"},{"line_number":216,"context_line":"response body when accepted. Evacuation is also asynchronous but returns HTTP"},{"line_number":217,"context_line":"200. Starting with the new microversion, every accepted evacuation request"},{"line_number":218,"context_line":"will return HTTP 202, whether or not it supplies ``availability_zone``. All"},{"line_number":219,"context_line":"four actions will return empty response bodies at the new microversion."},{"line_number":220,"context_line":"Acceptance does not mean that scheduling or the move has succeeded."},{"line_number":221,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"f8d0c582_888f5295","line":218,"range":{"start_line":216,"start_character":29,"end_line":218,"end_character":20},"updated":"2026-11-13 02:59:38.000000000","message":"this is different than AZ things but I am ++ to fix this as it is small fix on same API we are improving.","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":true,"context_lines":[{"line_number":225,"context_line":"microversion 2.95. No response body schema or URL parameter changes will be"},{"line_number":226,"context_line":"required."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"The API will return the following new error responses:"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* HTTP 400 if the requested availability zone does not exist."},{"line_number":231,"context_line":"* HTTP 400 if an explicitly requested host does not belong to the explicitly"}],"source_content_type":"text/x-rst","patch_set":3,"id":"638f4204_9fe6935d","line":228,"range":{"start_line":228,"start_character":34,"end_line":228,"end_character":43},"updated":"2026-11-13 02:59:38.000000000","message":"nit: these APIs already return these error code so those are not new to APIs but new scenarios to existing error codes","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7455aaa24fac2e65ab88e038187d80648785805b","unresolved":true,"context_lines":[{"line_number":225,"context_line":"microversion 2.95. No response body schema or URL parameter changes will be"},{"line_number":226,"context_line":"required."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"The API will return the following new error responses:"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* HTTP 400 if the requested availability zone does not exist."},{"line_number":231,"context_line":"* HTTP 400 if an explicitly requested host does not belong to the explicitly"}],"source_content_type":"text/x-rst","patch_set":3,"id":"feb8dc1d_8f360357","line":228,"range":{"start_line":228,"start_character":34,"end_line":228,"end_character":43},"in_reply_to":"638f4204_9fe6935d","updated":"2026-11-13 11:57:02.000000000","message":"the codes are not new but the checks are.\nbut i can rewrod if you prefer.","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"877de87c8f272b1eec7bebdb6ac6daa267acc4c4","unresolved":false,"context_lines":[{"line_number":225,"context_line":"microversion 2.95. No response body schema or URL parameter changes will be"},{"line_number":226,"context_line":"required."},{"line_number":227,"context_line":""},{"line_number":228,"context_line":"The API will return the following new error responses:"},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"* HTTP 400 if the requested availability zone does not exist."},{"line_number":231,"context_line":"* HTTP 400 if an explicitly requested host does not belong to the explicitly"}],"source_content_type":"text/x-rst","patch_set":3,"id":"982ce82b_26561591","line":228,"range":{"start_line":228,"start_character":34,"end_line":228,"end_character":43},"in_reply_to":"feb8dc1d_8f360357","updated":"2026-11-13 16:33:50.000000000","message":"its ok either way for me as it is just nit.","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":false,"context_lines":[{"line_number":245,"context_line":""},{"line_number":246,"context_line":"Both will default to ``PROJECT_MANAGER_OR_ADMIN``, matching the corresponding"},{"line_number":247,"context_line":"migration policies for requests without a destination. Deployers will be able"},{"line_number":248,"context_line":"to override the new rules separately. Cold and live migration requests with"},{"line_number":249,"context_line":"an AZ will need to pass the new AZ policy as well as the corresponding"},{"line_number":250,"context_line":"migration policy for requests without a destination. Requests specifying a"},{"line_number":251,"context_line":"host must also pass the existing host authorization, including when both"},{"line_number":252,"context_line":"host and AZ are supplied."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Host and AZ selection for resize will require additional policy checks"},{"line_number":255,"context_line":"that default to ``PROJECT_MANAGER_OR_ADMIN``, as well as the existing resize"}],"source_content_type":"text/x-rst","patch_set":3,"id":"440c3787_833b1f65","line":252,"range":{"start_line":248,"start_character":38,"end_line":252,"end_character":25},"updated":"2026-11-13 02:59:38.000000000","message":"++","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"b93aa6d9b31374369264cb7f8b2840620fe700a2","unresolved":true,"context_lines":[{"line_number":251,"context_line":"host must also pass the existing host authorization, including when both"},{"line_number":252,"context_line":"host and AZ are supplied."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Host and AZ selection for resize will require additional policy checks"},{"line_number":255,"context_line":"that default to ``PROJECT_MANAGER_OR_ADMIN``, as well as the existing resize"},{"line_number":256,"context_line":"policy. Resize without a requested destination will retain its existing"},{"line_number":257,"context_line":"member-level authorization."},{"line_number":258,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"1e464c95_b8e38026","line":255,"range":{"start_line":254,"start_character":0,"end_line":255,"end_character":44},"updated":"2026-11-13 02:59:38.000000000","message":"Project manager cannot pass the \u0027host\u0027 as they do not about it. Similar to other migration operations, we need two policies here.\n\n- Specifying \u0027host\u0027: the project manager cannot pass \u0027 host \u0027, so we should default it to admin only. Same as migration operation.\n\n       ``os_compute_api:servers:resize:host``: ADMIN\n\n- Specifying \u0027az\u0027: as project manager can request this, the new policy can be default to PROJECT_MEMBER_OR_ADMIN.\n\n       ``os_compute_api:servers:resize:az``: PROJECT_MEMBER_OR_ADMIN\n     \n- Specifying \u0027host\u0027 and \u0027az\u0027: we need to check both policies\n\n       ``os_compute_api:servers:resize:host``: ADMIN\n       ``os_compute_api:servers:resize:az``: PROJECT_MEMBER_OR_ADMIN","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7455aaa24fac2e65ab88e038187d80648785805b","unresolved":true,"context_lines":[{"line_number":251,"context_line":"host must also pass the existing host authorization, including when both"},{"line_number":252,"context_line":"host and AZ are supplied."},{"line_number":253,"context_line":""},{"line_number":254,"context_line":"Host and AZ selection for resize will require additional policy checks"},{"line_number":255,"context_line":"that default to ``PROJECT_MANAGER_OR_ADMIN``, as well as the existing resize"},{"line_number":256,"context_line":"policy. Resize without a requested destination will retain its existing"},{"line_number":257,"context_line":"member-level authorization."},{"line_number":258,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"b1715d83_30270f6a","line":255,"range":{"start_line":254,"start_character":0,"end_line":255,"end_character":44},"in_reply_to":"1e464c95_b8e38026","updated":"2026-11-13 11:57:02.000000000","message":"actully ya that more what i was orginally thinking i can incopreate that to make it more clear.","commit_id":"f57b2680c8ee714402160706c7b06c9995165c78"}]}