)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"93ad7b34198159c30a3d96aface86ec9a263e728","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"14d76776_ae24d336","updated":"2025-12-09 19:33:39.000000000","message":"The code check will fail since the 2026.2 template is not up yet - I will rebase my changes once it is up.","commit_id":"a9614c0f42c37fb44a386aa3eacc91ea0f8fa658"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"66331125_cca657a2","updated":"2025-12-15 18:47:07.000000000","message":"Thanks for the feedbacks, Sean.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"670d04ca_5535981f","updated":"2025-12-15 12:49:04.000000000","message":"i dont disagree with the idea of completing the network cleanup\nsooner by activating the destiont port bidnign and cleaning up the soruce port binding but the proposal misrepresent when neutron is required to supprot routing packets too and form the destination. it is required to supprot that form pre-live-migrate due to the api contract to network-vif-plugged.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"8400bdab_eac976f6","in_reply_to":"670d04ca_5535981f","updated":"2025-12-15 18:47:07.000000000","message":"Please correct me if I\u0027m wrong (likely I am :(). \n\nFrom my understanding of the code + our discussion previously is that port bindings are more or less a state of a port (i.e., which host it is bind to). And we have the core mainstream Neutron drivers (e.g., OVN) which supports reading rARP from QEMU and perform the network switchover automatically - meaning it can function even without the concept of port bindings?\n\nBut as discussed previously, you mentioned that many 3rd party drivers are lacking this support and thus I assume they rely on the port binding activation request from Nova to perform the switchover?\n\nSo \"activating dest port binding\" may be a \"network cleanup\" for L2 drivers that support this feature, but it means more of \"ok, all traffic goes to destination only\" imo.\n\nRegarding \"routing packets [to] and [from] the destination\", do you mean the driver should basically have two paths, one to source and one to dest? I think this can be very tricky for L3 drivers because the driver cannot route traffic to two instances with the same IP address, and thus only one active path can exist.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"fb75ab818b4fb2c0e58ff95e134907cb2cb7c1c0","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":3,"id":"6f20f8a8_76d790c8","in_reply_to":"8400bdab_eac976f6","updated":"2025-12-22 16:58:02.000000000","message":"I\u0027ve updated the spec with what we\u0027ve discussed here. Thanks for helping with the review!","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"8a03396a332610c0e77327bd232f277a337462bb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"d774a320_c0fc4cba","updated":"2026-03-30 14:19:18.000000000","message":"For the case of the Calico driver, I am not yet understanding the benefit of this proposal.  Of course I may be misunderstanding something!","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"aa347f76db3cfbecec46cc5770054fda68f60c24","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"6ec6c3c0_b8d041d9","updated":"2026-04-01 19:10:24.000000000","message":"Thanks for the feedback, Nell!","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0cc45edc92bc819150712ccf0255e910594dcd0a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"9bb719dd_79d1d73c","updated":"2026-04-01 19:54:54.000000000","message":"just replying to a spcific comment i know i need to find tiem to revew this end to end but i have not had tiem to do that today.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"8a7719216fc60943c247843bc8589b98618464f8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"35e5da13_98500549","in_reply_to":"9bb719dd_79d1d73c","updated":"2026-04-01 20:23:10.000000000","message":"Thank you and no rush Sean, I know 2026.1 was just released today :D.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"}],"specs/2026.2/approved/refine-network-setup-procedure-in-live-migrations.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":39,"context_line":"      handlers during the Migration stage or in the Post Live Migration stage."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"* For Neutron backends that don’t support the port binding extension API,"},{"line_number":42,"context_line":"  network setup takes place in the Post Live Migration stage."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Nova does not provide an option for virt drivers to explicitly set up the"},{"line_number":45,"context_line":"instance network connectivity on the destination host prior to the end of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fabf5ba3_43593c53","line":42,"updated":"2025-12-15 12:49:04.000000000","message":"we are planning to reventulaly remove supprot for such backend\n\nit was ment to be done years ago but we never got aroudn to doing it.\n\nas in i propsoed deprecating supprot for this in antelope with the intent ot remove it in caracal.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"7a36debe1b6545d0ab2bd9ea8c6b0ba02e57a978","unresolved":true,"context_lines":[{"line_number":39,"context_line":"      handlers during the Migration stage or in the Post Live Migration stage."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"* For Neutron backends that don’t support the port binding extension API,"},{"line_number":42,"context_line":"  network setup takes place in the Post Live Migration stage."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Nova does not provide an option for virt drivers to explicitly set up the"},{"line_number":45,"context_line":"instance network connectivity on the destination host prior to the end of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"250b7a0e_9c1f8c78","line":42,"in_reply_to":"07cacd8f_c55f7996","updated":"2025-12-17 14:58:23.000000000","message":"well you cant remove that entirly yet\nwhact you can say in the spec is that this functionalty will only be supproted if multiple portbinigns are supported but we will ahve to still support the old flow where its not until the ohter code path is remvoed.\n\nso you can make it a hard requirement for the new behvior.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"d967e36d07988646ebd00ffe3b7b9d48d3233e62","unresolved":true,"context_lines":[{"line_number":39,"context_line":"      handlers during the Migration stage or in the Post Live Migration stage."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"* For Neutron backends that don’t support the port binding extension API,"},{"line_number":42,"context_line":"  network setup takes place in the Post Live Migration stage."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Nova does not provide an option for virt drivers to explicitly set up the"},{"line_number":45,"context_line":"instance network connectivity on the destination host prior to the end of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"f577e585_4e7dae2b","line":42,"in_reply_to":"250b7a0e_9c1f8c78","updated":"2025-12-17 15:00:51.000000000","message":"Make sense, will do.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e4b816e32917878808465f8c9fd98b8a627cf717","unresolved":true,"context_lines":[{"line_number":39,"context_line":"      handlers during the Migration stage or in the Post Live Migration stage."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"* For Neutron backends that don’t support the port binding extension API,"},{"line_number":42,"context_line":"  network setup takes place in the Post Live Migration stage."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Nova does not provide an option for virt drivers to explicitly set up the"},{"line_number":45,"context_line":"instance network connectivity on the destination host prior to the end of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"c895c5f6_e8ec00f8","line":42,"in_reply_to":"87e30745_dde0b01c","updated":"2025-12-17 10:26:16.000000000","message":"i think we should deprecate it this cycle and perhaps remove it next cycle when you work on this feature. or as a seperate cleanup.\n\nthe removal cant happen until we issue the deprecation formally in a skip level upgrade release i.e. one of the .1 releases\n\nneutron added the multipel fport bidnig supprot around pike\nhttps://specs.openstack.org/openstack/neutron-specs/specs/backlog/pike/portbinding_information_for_nova.html\n\nand we added the usage of it to nova in rocky \nhttps://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/neutron-new-port-binding-api.html\n\nsupport for live migration without this was intened to be remvoed trian or ussuri orginally but that never happend.\nso i think its time to actully do that clean up because it constantly makes thigns like this harder to reason about.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"691dc7a6e651109733cca2b562f26711e13eed78","unresolved":true,"context_lines":[{"line_number":39,"context_line":"      handlers during the Migration stage or in the Post Live Migration stage."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"* For Neutron backends that don’t support the port binding extension API,"},{"line_number":42,"context_line":"  network setup takes place in the Post Live Migration stage."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Nova does not provide an option for virt drivers to explicitly set up the"},{"line_number":45,"context_line":"instance network connectivity on the destination host prior to the end of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"07cacd8f_c55f7996","line":42,"in_reply_to":"c895c5f6_e8ec00f8","updated":"2025-12-17 14:55:39.000000000","message":"Even better :D! I\u0027ll modify the spec to not address the case where drivers don\u0027t support the binding-extended API, given that it should be deprecated soonish.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":39,"context_line":"      handlers during the Migration stage or in the Post Live Migration stage."},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"* For Neutron backends that don’t support the port binding extension API,"},{"line_number":42,"context_line":"  network setup takes place in the Post Live Migration stage."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"Nova does not provide an option for virt drivers to explicitly set up the"},{"line_number":45,"context_line":"instance network connectivity on the destination host prior to the end of the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"87e30745_dde0b01c","line":42,"in_reply_to":"fabf5ba3_43593c53","updated":"2025-12-15 18:47:07.000000000","message":"Maybe as part of this, we remove the support? Or at least start some effort on deprecating this.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":46,"context_line":"virt driver’s migration workflow. The only workaround is to run the"},{"line_number":47,"context_line":"`post_method` provided by `Nova`_, which contradicts the concept of “post"},{"line_number":48,"context_line":"live migration” as the `post_method` is supposed to run after the virt driver"},{"line_number":49,"context_line":"has finished the live migration."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"Nova does not have the ability to `roll back the changes`_ made to networking"},{"line_number":52,"context_line":"if they are migrated but live migrations end up failing."}],"source_content_type":"text/x-rst","patch_set":3,"id":"cf4ba05a_fc878f27","line":49,"updated":"2025-12-15 12:49:04.000000000","message":"not quite. its intened to run after the point where a migration cannot be aborted or reverted.\nthat is subtle diffent.\n\nit started as the point where the migrtation was completed and then became the point where the vm is running on the dsitnation which is not the same at least for post-copy  and  it could be moved even earlier.\n\n\ntoday its expected to be triggers as soon as we have reached that point of no return where the vm will not be resumted on the source host.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":46,"context_line":"virt driver’s migration workflow. The only workaround is to run the"},{"line_number":47,"context_line":"`post_method` provided by `Nova`_, which contradicts the concept of “post"},{"line_number":48,"context_line":"live migration” as the `post_method` is supposed to run after the virt driver"},{"line_number":49,"context_line":"has finished the live migration."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"Nova does not have the ability to `roll back the changes`_ made to networking"},{"line_number":52,"context_line":"if they are migrated but live migrations end up failing."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fb6190c3_c55b343c","line":49,"in_reply_to":"cf4ba05a_fc878f27","updated":"2025-12-15 18:47:07.000000000","message":"Understood, I\u0027ll modify the statement here. The core idea I think still applies (that we need to extract the network part out of post live migration).","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":49,"context_line":"has finished the live migration."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"Nova does not have the ability to `roll back the changes`_ made to networking"},{"line_number":52,"context_line":"if they are migrated but live migrations end up failing."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"This introduces a few issues:"},{"line_number":55,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"dbb5adf6_8cf758af","line":52,"updated":"2025-12-15 12:49:04.000000000","message":"this depend on where it fails.\nwe do prior to post live migrate being called.\n\nif we fail in pre-live migrate or migrate we willl clean up the inactive port binding as part of the revert logic.\n\nhowever we do not supprot revert once we progres pass teh call to migrate.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":49,"context_line":"has finished the live migration."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"Nova does not have the ability to `roll back the changes`_ made to networking"},{"line_number":52,"context_line":"if they are migrated but live migrations end up failing."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"This introduces a few issues:"},{"line_number":55,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"52a5bb21_e7127754","line":52,"in_reply_to":"dbb5adf6_8cf758af","updated":"2025-12-15 18:47:07.000000000","message":"Right, I can be more specific here. The link I put here is referring to the last case you mentioned (and the previous bug report).","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"* Difficulty for developers to understand the live migration workflow, and a"},{"line_number":57,"context_line":"  lack of clarity on when exactly network connectivity is set up on the"},{"line_number":58,"context_line":"  destination host."},{"line_number":59,"context_line":"* Code for network updates with backends that support or don’t support the"},{"line_number":60,"context_line":"  port binding extension API is scattered across different stages and"},{"line_number":61,"context_line":"  functions, increasing maintenance costs."}],"source_content_type":"text/x-rst","patch_set":3,"id":"69fde2ae_05462119","line":58,"updated":"2025-12-15 12:49:04.000000000","message":"it is done in pre-live migrate\n\nthe neutron backend is required to only send the network-vif-plugged event when the networkign is configure on the hsot.\n\nits also requied to do this for any host with a port bindign not just the host with the active binding.\n\novn used to break both api contract now it only breaks the first and will comply with the second.\n\nmany out of tree dirver did nto respect this api contract but the intree ones did","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":55,"context_line":""},{"line_number":56,"context_line":"* Difficulty for developers to understand the live migration workflow, and a"},{"line_number":57,"context_line":"  lack of clarity on when exactly network connectivity is set up on the"},{"line_number":58,"context_line":"  destination host."},{"line_number":59,"context_line":"* Code for network updates with backends that support or don’t support the"},{"line_number":60,"context_line":"  port binding extension API is scattered across different stages and"},{"line_number":61,"context_line":"  functions, increasing maintenance costs."}],"source_content_type":"text/x-rst","patch_set":3,"id":"0df45d25_0c9716ad","line":58,"in_reply_to":"69fde2ae_05462119","updated":"2025-12-15 18:47:07.000000000","message":"Similar to what\u0027s mentioned in the previous comment, this is more referring to \"lack of clarity on when network switchover is done\" (i.e., when the port bindings on dest are activated).\n\nI\u0027ve read about the network-vif-plugged and it makes sense to me - we are working on to get calico (the driver we use) support that.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  lack of clarity on when exactly network connectivity is set up on the"},{"line_number":58,"context_line":"  destination host."},{"line_number":59,"context_line":"* Code for network updates with backends that support or don’t support the"},{"line_number":60,"context_line":"  port binding extension API is scattered across different stages and"},{"line_number":61,"context_line":"  functions, increasing maintenance costs."},{"line_number":62,"context_line":"* A lack of granular control for virt drivers on when network connectivity"},{"line_number":63,"context_line":"  can be set up on the destination host during migrations."}],"source_content_type":"text/x-rst","patch_set":3,"id":"1853560a_9045045a","line":60,"updated":"2025-12-15 12:49:04.000000000","message":"its not the port bindign extension https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings.py\n\nthat is mandatory\n\nthe extension your refering to is  https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings_extended.py\n\nwhich introduced the concept of multiple port bindings.\n\nthat is optional for some operations and required for others (cross cell cold migraiton)\n\nthe intent was to make it mandaroy for all operations eventually.\n\nthe existing complexity in nova is just because we have not enforced that yet.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":57,"context_line":"  lack of clarity on when exactly network connectivity is set up on the"},{"line_number":58,"context_line":"  destination host."},{"line_number":59,"context_line":"* Code for network updates with backends that support or don’t support the"},{"line_number":60,"context_line":"  port binding extension API is scattered across different stages and"},{"line_number":61,"context_line":"  functions, increasing maintenance costs."},{"line_number":62,"context_line":"* A lack of granular control for virt drivers on when network connectivity"},{"line_number":63,"context_line":"  can be set up on the destination host during migrations."}],"source_content_type":"text/x-rst","patch_set":3,"id":"fc914096_8f924592","line":60,"in_reply_to":"1853560a_9045045a","updated":"2025-12-15 18:47:07.000000000","message":"Ahh ok. Sorry I was using the term based on my reading of this function: https://github.com/openstack/nova/blob/1e14d75268caf111d324647052e47fbe54fa73be/nova/network/neutron.py#L1520, which is used in `migrate_instance_start`.\n\nI will be clear in the document that I\u0027m referring to [port binding-extended] API.\n\n[port binding-extended]: https://github.com/openstack/neutron-lib/blob/master/neutron_lib/api/definitions/portbindings_extended.py#L46","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":79,"context_line":"As a virt driver developer, I would like Nova to properly roll back the"},{"line_number":80,"context_line":"changes made to the instance’s networking when live migrations fail, so"},{"line_number":81,"context_line":"that it is safe for the driver to switch connectivity over to the"},{"line_number":82,"context_line":"destination host prior to live migrations finishing."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"As a cloud operator, I would like to configure Nova to instruct the virt"},{"line_number":85,"context_line":"driver to set up the instance network connectivity on the destination"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ecb2d683_2d8bd704","line":82,"updated":"2025-12-15 12:49:04.000000000","message":"so this is not in the scodpe of a virt driver developer for one.\n\nthe migration flow is orcstrated at a much higher lvel.\n\ncurrently we define when rollback can happne and activating the port binding on the destition is defiend as somethign that happens after rollback is nolonger allowed.\n\nso your not really asking for nova to supprot rollback of the networkign\nyour ask for us to mvoe the activation of the network bidng before the point of no return where rollback is not allowed.\n\nnot that neutron backend are quired to make the network connectivity on the dest function in pre-live migrate today. Any neutron backend that is not capable of routing a netowrk packet recived form an interface on the network ackend is not allowed to report network-vif-plugged. many break that contract today causing network downtime.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":79,"context_line":"As a virt driver developer, I would like Nova to properly roll back the"},{"line_number":80,"context_line":"changes made to the instance’s networking when live migrations fail, so"},{"line_number":81,"context_line":"that it is safe for the driver to switch connectivity over to the"},{"line_number":82,"context_line":"destination host prior to live migrations finishing."},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"As a cloud operator, I would like to configure Nova to instruct the virt"},{"line_number":85,"context_line":"driver to set up the instance network connectivity on the destination"}],"source_content_type":"text/x-rst","patch_set":3,"id":"9c10f9c3_4c0a9c75","line":82,"in_reply_to":"ecb2d683_2d8bd704","updated":"2025-12-15 18:47:07.000000000","message":"Yes, I believe this is asking to treat activating port bindings as something that is rollback-able, hence not something that falls into \"the point of no return where rollback is not allowed\". Given what we previously discussed, I think it\u0027s definitely rollback-able. \n\nAs previously mentioned, I find it tricky for L3 drivers to have 2 active path at the same time for the same IP address.\n\nRegardless, the rollbacks should be at least able to cover the case identified [here], no?\n\n[here]: https://bugs.launchpad.net/nova/+bug/1788014","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":95,"context_line":"Extract all network-related code from the current live migration workflow and"},{"line_number":96,"context_line":"group them into four high-level functions. Each will do the following:"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* `pre_network_setup`"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"    * Pre-set-up networking on the destination host for the instance being"},{"line_number":101,"context_line":"      migrated."},{"line_number":102,"context_line":"    * ✅ port-binding-extension-API: Create new port bindings on the"},{"line_number":103,"context_line":"      destination host for the instance being migrated."},{"line_number":104,"context_line":"    * ❌ port-binding-extension-API: Do nothing."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* `set_up_network_on_destination`"},{"line_number":107,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"e4d9aa86_bc6b8590","line":104,"range":{"start_line":98,"start_character":0,"end_line":104,"end_character":47},"updated":"2025-12-15 12:49:04.000000000","message":"emojis and bullet list are both marker of ai usage in my experience\n\nai usage is fine as long as its disclosed https://openinfra.org/legal/ai-policy\n\nno offence ment if this si all your own work i just said i would ask\nin case you have used ai and were not aware of the policy.\n\neffctivly all you need to d is add `Assisted-By: \u003ctool\u003e \u003coptionally model\u003e`\ni.e. Assisted-By: Cursor composer-1\n\nif most of the output is unmodified it woudl be `Generated-By:`\nthat is unlikely to be the case for a spec espiucally isnce i recognise mouch of this content form the bug and other converstaion we had on the topic.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e4b816e32917878808465f8c9fd98b8a627cf717","unresolved":false,"context_lines":[{"line_number":95,"context_line":"Extract all network-related code from the current live migration workflow and"},{"line_number":96,"context_line":"group them into four high-level functions. Each will do the following:"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* `pre_network_setup`"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"    * Pre-set-up networking on the destination host for the instance being"},{"line_number":101,"context_line":"      migrated."},{"line_number":102,"context_line":"    * ✅ port-binding-extension-API: Create new port bindings on the"},{"line_number":103,"context_line":"      destination host for the instance being migrated."},{"line_number":104,"context_line":"    * ❌ port-binding-extension-API: Do nothing."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* `set_up_network_on_destination`"},{"line_number":107,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"cfc83e1a_4b73330d","line":104,"range":{"start_line":98,"start_character":0,"end_line":104,"end_character":47},"in_reply_to":"c7b30115_405b5da5","updated":"2025-12-17 10:26:16.000000000","message":"no its fine just confirming\n\nwe normally don\u0027t have emojis but we have in teh past so its allowed\n\ni just done see this often outside of ai generate patches which relaly like adding them so i siad i woudl ask. this is fine as it is","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":95,"context_line":"Extract all network-related code from the current live migration workflow and"},{"line_number":96,"context_line":"group them into four high-level functions. Each will do the following:"},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"* `pre_network_setup`"},{"line_number":99,"context_line":""},{"line_number":100,"context_line":"    * Pre-set-up networking on the destination host for the instance being"},{"line_number":101,"context_line":"      migrated."},{"line_number":102,"context_line":"    * ✅ port-binding-extension-API: Create new port bindings on the"},{"line_number":103,"context_line":"      destination host for the instance being migrated."},{"line_number":104,"context_line":"    * ❌ port-binding-extension-API: Do nothing."},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* `set_up_network_on_destination`"},{"line_number":107,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"c7b30115_405b5da5","line":104,"range":{"start_line":98,"start_character":0,"end_line":104,"end_character":47},"in_reply_to":"e4d9aa86_bc6b8590","updated":"2025-12-15 18:47:07.000000000","message":"Appreciate the heads up, but I assure you nothing here is AI generated :) (well there may be less mistakes if it\u0027s AI generated lol). It\u0027s my personal preference to use bullet points + simple emojis to just make things easier to read, instead of typing \"for backends supports vs. for backends doesn\u0027t support...\". Red vs. green here makes it easy (at least for me) to quickly spot the info that I\u0027m interested in.\n\nWith that being said, I\u0027m happy to change this if it\u0027s not the convention of writing specs.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":152,"context_line":""},{"line_number":153,"context_line":"1. Pre Live Migration Stage"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"    * Call pre_network_setup."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"2. Migration Stage (with virt drivers)"},{"line_number":158,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"47017ef7_28f54fa2","line":155,"updated":"2025-12-15 12:49:04.000000000","message":"so at this point neutron is currently required to supprot reciving traffic form teh vm and routing it. its also where we tell neutron that it shoudl mirror the traffic or prepare to route traffic for the vm to the destionation.\n\n\nfor l2 network backend liek ml2/ovs, linux bridge or sriov nic agent the desting fo the integration was that mac leaning frames would be used ot reroute the trafic when the vm was beign unpaused.\n\nOVN now uses the same mac learning frams to activate its routing to the desitiaion\nconfroming to the orgianl design intent for live migration.\n\nthe activation state of the neutorn prot binding is explictly not ment to be used to gate network connectiviy.\n\nit only identifies the primary destination for the packet but any host with a port bidning (active or inactinve) is requried to supprot sending packet too a vm and reciviing packets form a vm.\n\nthe swithc over of the ingress traffic to the vm is intened to be contol by the RARP packets or any new egress packet form the vm, not by the neutron api.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"81164b82d40246f054b1bc6975b1cc719b38e4fe","unresolved":true,"context_lines":[{"line_number":152,"context_line":""},{"line_number":153,"context_line":"1. Pre Live Migration Stage"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"    * Call pre_network_setup."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"2. Migration Stage (with virt drivers)"},{"line_number":158,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3920a2f4_1037f783","line":155,"in_reply_to":"17c3ecad_39e44e3d","updated":"2025-12-17 22:41:31.000000000","message":"As I\u0027m addressing the comments, I\u0027m thinking about categorizing Neutron drivers in the following way - Please lemme know if it makes sense or not, and maybe what are some drivers on top of your head that would fit in each category. \n\nIn the happy path:\n1. If a driver has the ability to send packets to and receive packets from source and destination, then the activation of port bindings is basically a no-op from the network connectivity perspective, because the driver knows how to mirror the packets and only one VM will be running.\n2. If a driver does not have the ability to send packets to or receive packets from  source and destination, but implements some sort of mechanism to switchover to destination automatically (e.g., the RARP packet), then activation of port bindings is a no-op from the network connectivity perspective (well, it can implement something to \"prepare to route traffic for the vm to the [destination]\" in pre-live-migration-stage to reduce the network downtime, ideally), because the \"trigger\" for setting up network connectivity on destination here is not the port binding activation call. \n\nIn both cases, as you pointed out, the state of the port bindings is not meant to gate network connectivity.\n\nIn the not-so-happy path:\n3. If a driver does not have the ability to send packets to or receive packets from source and destination, nor does it implement some sort of mechanism to switchover to destination automatically when the instance resumes, then it must rely on port binding activation request to perform the switchover - which the switchover means establishing network connectivity on the destination.\n\nIn this case, OVN would be in category 1 and calico (and from my understanding, the l3 drivers) would be category 3. First, I don\u0027t think it\u0027s possible for L3 drivers to have two instances with the same IP address - it will create a conflict and some packets will be routed to source and some will be routed to dest. Second, as we discussed this before, it may be tricky for L3 drivers to implement the RARP capturing feature and many third party drivers lack this support. Also, switchover based on packets received from a VM is also tricky, because let\u0027s say the L3 driver is programming the ipsets \u0026 iptable, then the packet will just be dropped, without letting the L3 driver know.\n\nSo the way I think about this is by activating port early, we provide an alternative way to lower the network loss time in live migrations for drivers, if, for whatever reason, the mentioned features cannot be implemented or easily implemented. And it\u0027s a no-harm thing for the good citizens that implements the additional features. Tho it makes perfect sense that the state of the port binding !\u003d the state of network connectivity - but some drivers may treat it differently.\n\nThanks a lot for helping!","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":152,"context_line":""},{"line_number":153,"context_line":"1. Pre Live Migration Stage"},{"line_number":154,"context_line":""},{"line_number":155,"context_line":"    * Call pre_network_setup."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"2. Migration Stage (with virt drivers)"},{"line_number":158,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"17c3ecad_39e44e3d","line":155,"in_reply_to":"47017ef7_28f54fa2","updated":"2025-12-15 18:47:07.000000000","message":"Yes, we talked about this. I put this in the \"Alternatives\" section. This shouldn\u0027t affect core Neutron drivers that much, but can be very beneficial to 3rd party drivers + L3 drivers.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":154,"context_line":""},{"line_number":155,"context_line":"    * Call pre_network_setup."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"2. Migration Stage (with virt drivers)"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"    * Generally, there are two main threads that monitor the progress of live"},{"line_number":160,"context_line":"      migrations: the one that listens to lifecycle events, and the one that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"cdeced5f_72e1cbbb","line":157,"updated":"2025-12-15 12:49:04.000000000","message":"this is very specific to the libvirt driver other dont really work the same","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":154,"context_line":""},{"line_number":155,"context_line":"    * Call pre_network_setup."},{"line_number":156,"context_line":""},{"line_number":157,"context_line":"2. Migration Stage (with virt drivers)"},{"line_number":158,"context_line":""},{"line_number":159,"context_line":"    * Generally, there are two main threads that monitor the progress of live"},{"line_number":160,"context_line":"      migrations: the one that listens to lifecycle events, and the one that"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fe5fe76_6c9ac375","line":157,"in_reply_to":"cdeced5f_72e1cbbb","updated":"2025-12-15 18:47:07.000000000","message":"Yes, the two methods here are from the libvirt driver, but at the same time, they are the only (?) ways to monitor anything in general - Either by listening to some sort of events, or query it every X seconds (or ms).\n\nOther drivers may have different ways, but I don\u0027t think they gonna fall out of these categories. They may support a subset of two functions or don\u0027t support at all, hence my idea is to make this compatible like how it\u0027s currently done: In post live migration stage, ensure port bindings are indeed updated.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":178,"context_line":"      `EVENT_LIFECYCLE_MIGRATION_NETWORK_SETUP` or"},{"line_number":179,"context_line":"      `EVENT_LIFECYCLE_MIGRATION_COMPLETED` events."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"3. Post Live Migration Stage"},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"    * Call `post_network_setup` to ensure network connectivity is indeed set"},{"line_number":184,"context_line":"      up on the destination host, which will call"}],"source_content_type":"text/x-rst","patch_set":3,"id":"31c95e0b_6cc922f7","line":181,"updated":"2025-12-15 12:49:04.000000000","message":"this is the point where we tell neutron that it can start tearign down the network configuration for the source host and that it can stop routing the traffic to multiple hosts\n\nwe do this by activitign the dest port binding and deletign the souce port binding.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":178,"context_line":"      `EVENT_LIFECYCLE_MIGRATION_NETWORK_SETUP` or"},{"line_number":179,"context_line":"      `EVENT_LIFECYCLE_MIGRATION_COMPLETED` events."},{"line_number":180,"context_line":""},{"line_number":181,"context_line":"3. Post Live Migration Stage"},{"line_number":182,"context_line":""},{"line_number":183,"context_line":"    * Call `post_network_setup` to ensure network connectivity is indeed set"},{"line_number":184,"context_line":"      up on the destination host, which will call"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afffbe6_c6ba4ffa","line":181,"in_reply_to":"31c95e0b_6cc922f7","updated":"2025-12-15 18:47:07.000000000","message":"Our idea is the same here, just that I think I didn\u0027t word it well in my document, and I\u0027ll fix that. In summary, here are my thoughts \u0026 questions for this + previous comments:\n\nFor L2 drivers, I get that it is possible to route traffics to both source and dest VMs because the interfaces have different MAC addresses but same IP address (right?). For L3 drivers, since traffic is route based on IP addresses, there can only be one active path. Thus, for L2 drivers, the \"switchover to dest instance\" \u003d \"stop routing traffic to source instance\", while for L3 drivers, the \"switchover to dest instance\" means \"clear the routing path to source and create the path to dest\". Naturally, the L3 drivers would need to rely on the activation to perform this switchover (not saying this is the only way, but definitely one way).\n\nHence I put network connectivity is set up on the destination host here, which a more appropriate term is \"network traffic has been routed to dest instance\" like you said.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"23dc304c3f276233e86e0e5f02485aa49b7672bf","unresolved":true,"context_lines":[{"line_number":188,"context_line":"      generate lifecycle events for live migrations."},{"line_number":189,"context_line":"    * Stale resources will be cleaned up."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"4. Rollback Live Migration Stage"},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"    * Call `rollback_network_changes` in case virt drivers called the"},{"line_number":194,"context_line":"      `set_up_network_on_destination` function in the Migration stage, but the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1493d25f_076afb28","line":191,"updated":"2025-12-15 12:49:04.000000000","message":"we do not allow rollback after the call to actully migrate the vm at the hypervior completes successfully.\n\nthe last point where rollback is allowe to be called is if it compelete with error\nso it will never be called once post live migrate is called.\n\nthis would be a change to the compute and conductor workflow not a diver level change.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"1519d7df24e75a62c327292c15cc7c76acffdbff","unresolved":true,"context_lines":[{"line_number":188,"context_line":"      generate lifecycle events for live migrations."},{"line_number":189,"context_line":"    * Stale resources will be cleaned up."},{"line_number":190,"context_line":""},{"line_number":191,"context_line":"4. Rollback Live Migration Stage"},{"line_number":192,"context_line":""},{"line_number":193,"context_line":"    * Call `rollback_network_changes` in case virt drivers called the"},{"line_number":194,"context_line":"      `set_up_network_on_destination` function in the Migration stage, but the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"77f2539c_ad14e660","line":191,"in_reply_to":"1493d25f_076afb28","updated":"2025-12-15 18:47:07.000000000","message":"Ah the numbered list may make things a bit confusing, but I mean the rollback should be called if \"the migration ends up failing\": the driver migration call ends up failing, not after when the driver call succeeds, and hence before post live migration is called. I\u0027ll fix this.","commit_id":"8dd4aa73f1eefe78be4623236e599e213ccc44b3"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"8a03396a332610c0e77327bd232f277a337462bb","unresolved":true,"context_lines":[{"line_number":38,"context_line":"1. Neutron drivers for networking architectures that set up network"},{"line_number":39,"context_line":"   connectivity for the instance on the destination host by leveraging the"},{"line_number":40,"context_line":"   network-vif-plugged event during the Pre Live Migration stage, while"},{"line_number":41,"context_line":"   preserving the network connectivity for the instance on the source host."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"   * The virt driver should ensure that the migrated VM will only be resumed"},{"line_number":44,"context_line":"     after the instance on the source host is paused (i.e., only one instance"}],"source_content_type":"text/x-rst","patch_set":6,"id":"4624fd64_1a24ce88","line":41,"updated":"2026-03-30 14:19:18.000000000","message":"I\u0027m not sure I understand every word of this description, but I would say that Calico does this.  Specifically in the sense that it prepares network connectivity on the target host at the same time as preserving connectivity on the source host, prior to the time when the VM goes live on the target host.\n\nHowever the wording \"leveraging the network-vif-plugged event\" sounds confused to me.  The Neutron driver does not \"leverage\" the network-vif-plugged event in the sense of _using_ it as a trigger for its own processing.  Rather the Neutron driver _sends_ the network-vif-plugged event to Nova in order to tell Nova when to proceed with the compute side of live migration, once networking is in place on the target host.  If that\u0027s what you meant, perhaps the wording here could be clarified.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"aa347f76db3cfbecec46cc5770054fda68f60c24","unresolved":true,"context_lines":[{"line_number":38,"context_line":"1. Neutron drivers for networking architectures that set up network"},{"line_number":39,"context_line":"   connectivity for the instance on the destination host by leveraging the"},{"line_number":40,"context_line":"   network-vif-plugged event during the Pre Live Migration stage, while"},{"line_number":41,"context_line":"   preserving the network connectivity for the instance on the source host."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"   * The virt driver should ensure that the migrated VM will only be resumed"},{"line_number":44,"context_line":"     after the instance on the source host is paused (i.e., only one instance"}],"source_content_type":"text/x-rst","patch_set":6,"id":"429ed17f_c9630ea8","line":41,"in_reply_to":"4624fd64_1a24ce88","updated":"2026-04-01 19:10:24.000000000","message":"From my understanding, Calico does not and cannot (?) do this. My impression from Sean is that the mainstream Neutron drivers (e.g., OVN) support network connectivity for both source and dest VM at the same time, where packets will be duplicated and sent to both sides (see [0], slide 39 and above). This is not really doable for L3 drivers, esp if BGP is used - we cannot have two route exists at the same time, and we do not duplicate packets. So \"prepares network connectivity on the target host\" is not enough: It should be \"has network connectivity on the target host\" instead.\n\nBy \"leveraging\", I mean \"take advantage of this feature\", because some third-party drivers (including calico right now - without the in-progress improvement) do not support generating the network-vif-plugged event during pre live migration. But I understand that the wording sounds a bit off. I\u0027ll make it clearer here.\n\n[0]: https://www.openvswitch.org/support/ovscon2022/slides/Live-migration-with-OVN.pdf","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"0cc45edc92bc819150712ccf0255e910594dcd0a","unresolved":true,"context_lines":[{"line_number":38,"context_line":"1. Neutron drivers for networking architectures that set up network"},{"line_number":39,"context_line":"   connectivity for the instance on the destination host by leveraging the"},{"line_number":40,"context_line":"   network-vif-plugged event during the Pre Live Migration stage, while"},{"line_number":41,"context_line":"   preserving the network connectivity for the instance on the source host."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"   * The virt driver should ensure that the migrated VM will only be resumed"},{"line_number":44,"context_line":"     after the instance on the source host is paused (i.e., only one instance"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bad6e414_c6831e35","line":41,"in_reply_to":"4624fd64_1a24ce88","updated":"2026-04-01 19:54:54.000000000","message":"The API contact to send \"network-vif-plugged\" is that the networking for the relevant port has been fully configured on the relevant compute host.\n\ni.e. if this is sent in pre-live-migration the contract that is creating is that if i was to instantly move the vm it should be able to transmit a packet and have that routed/process properly without packet loss.\n\n\nthe original reason network-vif-plugged event were first introduced was for reliable dhcp. i.e. so that nova could know that if we start a vm everythign requried for the vm to be able to get an ip via dhcp (all l2/l3 configuratoin) had been completed.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"8a7719216fc60943c247843bc8589b98618464f8","unresolved":true,"context_lines":[{"line_number":38,"context_line":"1. Neutron drivers for networking architectures that set up network"},{"line_number":39,"context_line":"   connectivity for the instance on the destination host by leveraging the"},{"line_number":40,"context_line":"   network-vif-plugged event during the Pre Live Migration stage, while"},{"line_number":41,"context_line":"   preserving the network connectivity for the instance on the source host."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"   * The virt driver should ensure that the migrated VM will only be resumed"},{"line_number":44,"context_line":"     after the instance on the source host is paused (i.e., only one instance"}],"source_content_type":"text/x-rst","patch_set":6,"id":"bdbfd8db_7bf21f70","line":41,"in_reply_to":"bad6e414_c6831e35","updated":"2026-04-01 20:23:10.000000000","message":"Indeed, so I think this is not the case for calico (or general l3 routing), because to \"be able to transmit a packet and have that routed/process properly without packet loss\", we\u0027ll need to:\n\n- Take down the route to the source side, because bad things will happen when two routes coexist.\n- Ensure the switches learn the updated path (i.e., to the dest VM) ASAP.\n\nThere may be some special setups to basically say one route has more priority than the other one and thus we don\u0027t need to take down the source route, but again, the switches need to learn which route is the correct route, and thus we will still have a small gap where the VM doesn\u0027t have connectivity, even if it\u0027s small.\n\nIn comparison, OVN doesn\u0027t have this problem (if I\u0027m understanding correctly) because two routes can coexist at the same time with packets duplicated.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":40,"context_line":"   network-vif-plugged event during the Pre Live Migration stage, while"},{"line_number":41,"context_line":"   preserving the network connectivity for the instance on the source host."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"   * The virt driver should ensure that the migrated VM will only be resumed"},{"line_number":44,"context_line":"     after the instance on the source host is paused (i.e., only one instance"},{"line_number":45,"context_line":"     of the VM is running at any given point in time)."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"2. Neutron drivers for networking architectures that implement a mechanism to"},{"line_number":48,"context_line":"   trigger network connectivity switchover when the migrated VM is resumed on"}],"source_content_type":"text/x-rst","patch_set":6,"id":"cf13cfc9_035d78a6","line":45,"range":{"start_line":43,"start_character":4,"end_line":45,"end_character":54},"updated":"2026-04-01 20:48:58.000000000","message":"this is not correct in that it imples this is the respoinsiblity fo the virt driver\n\nthere is infact no virtdriver that has the ablity to do this\n\nwhen a virt dirver start a live migration we delegate the pausing of the vm and its resumtion entirly to the hypervior i.e. libvirt/hyperv/vmware\n\nnova drives everyting up to the point when we call migrate on the hypervioer \nthen we monitro the progres of the job and finaly we regain management of the lifecycle of the vm either when the migraiton complete succsesfuly in post-live-migrate or if its aborted based on timeout or an admin action.\n\nto be clear the virt is not respocneabel for ensuring the vm is only runnign on one host at a tiem that a contract the hypervior enfoces and one that we simplely rely on in nova.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"6d06031c6ece2a66bd28f016fd1ccddfb63b84e9","unresolved":true,"context_lines":[{"line_number":40,"context_line":"   network-vif-plugged event during the Pre Live Migration stage, while"},{"line_number":41,"context_line":"   preserving the network connectivity for the instance on the source host."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"   * The virt driver should ensure that the migrated VM will only be resumed"},{"line_number":44,"context_line":"     after the instance on the source host is paused (i.e., only one instance"},{"line_number":45,"context_line":"     of the VM is running at any given point in time)."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"2. Neutron drivers for networking architectures that implement a mechanism to"},{"line_number":48,"context_line":"   trigger network connectivity switchover when the migrated VM is resumed on"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ebba4c2f_29bf390a","line":45,"range":{"start_line":43,"start_character":4,"end_line":45,"end_character":54},"in_reply_to":"cf13cfc9_035d78a6","updated":"2026-04-02 17:50:23.000000000","message":"Right, I mean the virtualization driver (e.g., libvirt) here, not the virt driver code in Nova. Will update the wording here.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"8a03396a332610c0e77327bd232f277a337462bb","unresolved":true,"context_lines":[{"line_number":47,"context_line":"2. Neutron drivers for networking architectures that implement a mechanism to"},{"line_number":48,"context_line":"   trigger network connectivity switchover when the migrated VM is resumed on"},{"line_number":49,"context_line":"   the destination host (e.g., capturing the RARP packet sent by QEMU when the"},{"line_number":50,"context_line":"   VM is resumed)."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"3. Neutron drivers for other networking architectures that do not support said"},{"line_number":53,"context_line":"   features and rely on the state of port bindings and activation requests in"}],"source_content_type":"text/x-rst","patch_set":6,"id":"16f67d5e_df7fd5e9","line":50,"updated":"2026-03-30 14:19:18.000000000","message":"Calico does this too: it detects the RARP/GARP packet from the resumed VM on the target host, and uses this to trigger routing handover.\n\nDid you intend the \"categories\" here to be exclusive?  I don\u0027t think they are.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"aa347f76db3cfbecec46cc5770054fda68f60c24","unresolved":true,"context_lines":[{"line_number":47,"context_line":"2. Neutron drivers for networking architectures that implement a mechanism to"},{"line_number":48,"context_line":"   trigger network connectivity switchover when the migrated VM is resumed on"},{"line_number":49,"context_line":"   the destination host (e.g., capturing the RARP packet sent by QEMU when the"},{"line_number":50,"context_line":"   VM is resumed)."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"3. Neutron drivers for other networking architectures that do not support said"},{"line_number":53,"context_line":"   features and rely on the state of port bindings and activation requests in"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5b59c601_78cef249","line":50,"in_reply_to":"16f67d5e_df7fd5e9","updated":"2026-04-01 19:10:24.000000000","message":"Categories here are exclusive - A driver can either support 1. Network connectivity for both src and dst VMs before live migration happens, 2. automatically switchover without depending on port binding activate requests (e.g., detect RARP/GARP packets), or 3. neither feature. Note that if a driver supports 1, from the network connectivity loss perspective, supporting 2 or not doesn\u0027t make a difference, because network connectivity is already up on the dest side before migration happens.\n\nWe are primarily focusing on the switchover behavior in this spec. In this case, calico with the detecting GARP feature would go to category 2, because the network-vif-plugged event sent by calico does not mean the dest VM has network connectivity. Rather, it means we\u0027ve done some preparation to reduce the switchover time, and the actual switchover still happens when the GARP packet is detected.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":49,"context_line":"   the destination host (e.g., capturing the RARP packet sent by QEMU when the"},{"line_number":50,"context_line":"   VM is resumed)."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"3. Neutron drivers for other networking architectures that do not support said"},{"line_number":53,"context_line":"   features and rely on the state of port bindings and activation requests in"},{"line_number":54,"context_line":"   order to identify when to switch the network connectivity over to the"},{"line_number":55,"context_line":"   instance running on the destination host."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"To both ensure that an instance\u0027s network state changes are reflected"},{"line_number":58,"context_line":"promptly with Neutron drivers of type [1] and [2], and reduce the network loss"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ef58b140_f0e63ae4","line":55,"range":{"start_line":52,"start_character":0,"end_line":55,"end_character":44},"updated":"2026-04-01 20:48:58.000000000","message":"the presence of a port bidning on a host is what determins if a network backend shoudl be able to recive traci form a vm/port form taht host\n\n\nthe active port bidning is effectivly the host to which packets dessted to the vm shoudl be routed.\n\n\neven for backend that dont supprot multiple portbianidn we encode this information in the port binding:profile in the migrating_to key\n\nso all neutron backedn are expected to respect that and supprot resciveing packts form the bidning:host_id or the binding:profile.migrating_to host","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"6d06031c6ece2a66bd28f016fd1ccddfb63b84e9","unresolved":true,"context_lines":[{"line_number":49,"context_line":"   the destination host (e.g., capturing the RARP packet sent by QEMU when the"},{"line_number":50,"context_line":"   VM is resumed)."},{"line_number":51,"context_line":""},{"line_number":52,"context_line":"3. Neutron drivers for other networking architectures that do not support said"},{"line_number":53,"context_line":"   features and rely on the state of port bindings and activation requests in"},{"line_number":54,"context_line":"   order to identify when to switch the network connectivity over to the"},{"line_number":55,"context_line":"   instance running on the destination host."},{"line_number":56,"context_line":""},{"line_number":57,"context_line":"To both ensure that an instance\u0027s network state changes are reflected"},{"line_number":58,"context_line":"promptly with Neutron drivers of type [1] and [2], and reduce the network loss"}],"source_content_type":"text/x-rst","patch_set":6,"id":"03fb89dd_c7d0f450","line":55,"range":{"start_line":52,"start_character":0,"end_line":55,"end_character":44},"in_reply_to":"ef58b140_f0e63ae4","updated":"2026-04-02 17:50:23.000000000","message":"So essentially it\u0027s still the question of whether the backend supports maintaining multiple routes? If a neutron driver respects `binding:profile.migrating_to`, it can be made into a category 1 driver, just that the API will change a bit?","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":62,"context_line":"implementation."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Nova does not have a specific stage for activating port bindings during live"},{"line_number":65,"context_line":"migrations. It may take place in the Migration stage or the Post Live"},{"line_number":66,"context_line":"Migration stage. For example, in the `libvirt` driver:"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* For pre-copy live migrations, activations may take place in lifecycle"},{"line_number":69,"context_line":"  handlers with an `event that doesn’t indicate “migration has finished”`_"}],"source_content_type":"text/x-rst","patch_set":6,"id":"6697719c_965f402f","line":66,"range":{"start_line":65,"start_character":12,"end_line":66,"end_character":15},"updated":"2026-04-01 20:48:58.000000000","message":"so that actully a littel inaccurate\n\ntoday it explcusive take please in the post-live-migration callback at which point we no longer supprot any revert or rollback.\n\n\nif post copy is enabel we consider the mighration \"completed\" for the purpose of callign the post-live-migration callback as it is no longer allowable to revert the migration and the vm is activly running on the destination\n\nwhen post-copy is disabled this only happens after the migration in the hypervioer is fully complete and the vm is also runnign on the destinations.\n\nthis is why we requrie network backens are capbale fo reciving and sendign traffic to the destination after pre-live-migrate adn why we require teh network-vif-plugged event today.\n\nthe activation of the destination prot binidnign  and clean up of the now inactive port binding for the shouce host is just that cleaning up the souce host refences to the vm since it is nolonger there.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"6d06031c6ece2a66bd28f016fd1ccddfb63b84e9","unresolved":true,"context_lines":[{"line_number":62,"context_line":"implementation."},{"line_number":63,"context_line":""},{"line_number":64,"context_line":"Nova does not have a specific stage for activating port bindings during live"},{"line_number":65,"context_line":"migrations. It may take place in the Migration stage or the Post Live"},{"line_number":66,"context_line":"Migration stage. For example, in the `libvirt` driver:"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* For pre-copy live migrations, activations may take place in lifecycle"},{"line_number":69,"context_line":"  handlers with an `event that doesn’t indicate “migration has finished”`_"}],"source_content_type":"text/x-rst","patch_set":6,"id":"023a4da1_6df4005f","line":66,"range":{"start_line":65,"start_character":12,"end_line":66,"end_character":15},"in_reply_to":"6697719c_965f402f","updated":"2026-04-02 17:50:23.000000000","message":"I see the confusion here. By Migration stage, I mean we try to check to see if we can activate port bindings before the migration actually finishes (this doesn\u0027t take place in the post live migration callback). For example [0], Nova, when received VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED, it will check if the job is completed and activate the port binding accordingly (but this is very likely a no-op, as VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED doesn\u0027t mean the migration has completed, so the if statement will be skipped in most of the cases).\n\nOf course, the end result is that we only activate port bindings when migration has completed, but my idea here is to bring out the need for refactoring the code - let\u0027s make it clearer by having a dedicated stage and let the virt driver decide when that should happen.\n\nI\u0027ll fix the wording here.\n\n[0]: https://github.com/openstack/nova/commit/aa87b9c288d316b85079e681e0df24354ec1912c#diff-67d0163175a798156def4ec53c18fa2ce6eba79b6400fa833a9219d3669e9a11","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":13734,"name":"Nell Jerram","email":"nell@tigera.io","username":"neiljerram"},"change_message_id":"8a03396a332610c0e77327bd232f277a337462bb","unresolved":true,"context_lines":[{"line_number":73,"context_line":"* For post-copy live migrations, activations may take place in lifecycle"},{"line_number":74,"context_line":"  handlers during the Migration stage or in the Post Live Migration stage."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Nova does not provide an option for virt drivers to explicitly activate port"},{"line_number":77,"context_line":"bindings on the destination host prior to the end of the virt driver’s"},{"line_number":78,"context_line":"migration workflow. The only “workaround” is to run the `post_method` provided"},{"line_number":79,"context_line":"by `Nova`_, which contradicts the concept of “post live migration”, as the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"cca94857_47235161","line":76,"updated":"2026-03-30 14:19:18.000000000","message":"As it is now coded, the Calico driver does not require an explicit binding activation step, and so - if I am understanding this proposal correctly - I am not sure what benefit is provided by the current proposal?  Of course it might not be the same situation for other drivers; I can only speak for Calico.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"aa347f76db3cfbecec46cc5770054fda68f60c24","unresolved":true,"context_lines":[{"line_number":73,"context_line":"* For post-copy live migrations, activations may take place in lifecycle"},{"line_number":74,"context_line":"  handlers during the Migration stage or in the Post Live Migration stage."},{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Nova does not provide an option for virt drivers to explicitly activate port"},{"line_number":77,"context_line":"bindings on the destination host prior to the end of the virt driver’s"},{"line_number":78,"context_line":"migration workflow. The only “workaround” is to run the `post_method` provided"},{"line_number":79,"context_line":"by `Nova`_, which contradicts the concept of “post live migration”, as the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"143f1546_733754e1","line":76,"in_reply_to":"cca94857_47235161","updated":"2026-04-01 19:10:24.000000000","message":"As mentioned by Sean in the previous comments, eventually it will be required for all drivers to support the port bindings extended API. However, you are correct in terms of the activation won\u0027t help calico that much because the switchover is done by detecting GARP instead of waiting for an activation request. The benefit of this spec is really for neutron drivers of category 3 (i.e., the calico driver rn), and tidy the network switchover code in Nova. \n\nIt\u0027s been a while since I wrote this. I need to review this doc and the code changes on networking-calico and get back to you on this.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Nova does not provide an option for virt drivers to explicitly activate port"},{"line_number":77,"context_line":"bindings on the destination host prior to the end of the virt driver’s"},{"line_number":78,"context_line":"migration workflow. The only “workaround” is to run the `post_method` provided"},{"line_number":79,"context_line":"by `Nova`_, which contradicts the concept of “post live migration”, as the"},{"line_number":80,"context_line":"`post_method` is supposed to run when the live migration operation has"},{"line_number":81,"context_line":"proceeded to a point where it cannot be aborted or rolled back."}],"source_content_type":"text/x-rst","patch_set":6,"id":"248d87b8_8e958a5d","line":78,"updated":"2026-04-01 20:48:58.000000000","message":"thsi is not entirly true we do provide that by calling the post-live-migration callback early. we allwo the virt driver to define whewn it consider it to be complete at any point before when the hypervior consider it to be complete which si what post-copy-live migration does today in the libvirt driver.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"6d06031c6ece2a66bd28f016fd1ccddfb63b84e9","unresolved":true,"context_lines":[{"line_number":75,"context_line":""},{"line_number":76,"context_line":"Nova does not provide an option for virt drivers to explicitly activate port"},{"line_number":77,"context_line":"bindings on the destination host prior to the end of the virt driver’s"},{"line_number":78,"context_line":"migration workflow. The only “workaround” is to run the `post_method` provided"},{"line_number":79,"context_line":"by `Nova`_, which contradicts the concept of “post live migration”, as the"},{"line_number":80,"context_line":"`post_method` is supposed to run when the live migration operation has"},{"line_number":81,"context_line":"proceeded to a point where it cannot be aborted or rolled back."}],"source_content_type":"text/x-rst","patch_set":6,"id":"443f6e1b_5c8225f9","line":78,"in_reply_to":"248d87b8_8e958a5d","updated":"2026-04-02 17:50:23.000000000","message":"But calling post-live-migration cb would mean activation + other-post-live-migration steps, no? There is no way to just do activation, but no other-post-live-migration steps.\n\nThe main idea of this spec is to extract the network part into its own stage.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":80,"context_line":"`post_method` is supposed to run when the live migration operation has"},{"line_number":81,"context_line":"proceeded to a point where it cannot be aborted or rolled back."},{"line_number":82,"context_line":""},{"line_number":83,"context_line":"Nova does not have the ability to `roll back the changes`_ made to port"},{"line_number":84,"context_line":"bindings if they are activated on destination hosts, but live migrations"},{"line_number":85,"context_line":"end up failing during the virt driver migration call."},{"line_number":86,"context_line":""},{"line_number":87,"context_line":"This introduces a few issues:"},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* Difficulty for developers to understand the live migration workflow, and a"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fb532afe_1a895bf1","line":86,"range":{"start_line":83,"start_character":0,"end_line":86,"end_character":1},"updated":"2026-04-01 20:48:58.000000000","message":"that is because we do not supprot rolling back live migration once we call migrate at the hypervior level.\n\nif that migrate request is acpapted by the hypervioer we do not supprot rollback the vm will either migrate succsfully or go to error by design since its generally unsafe to attempt automatic recovey at that point.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":88,"context_line":""},{"line_number":89,"context_line":"* Difficulty for developers to understand the live migration workflow, and a"},{"line_number":90,"context_line":"  lack of clarity on when exactly port bindings are activated on the"},{"line_number":91,"context_line":"  destination host."},{"line_number":92,"context_line":""},{"line_number":93,"context_line":"* Code for network updates is scattered across different stages and functions,"},{"line_number":94,"context_line":"  increasing maintenance costs."}],"source_content_type":"text/x-rst","patch_set":6,"id":"4ad91fdb_c16d0073","line":91,"updated":"2026-04-01 20:48:58.000000000","message":"they are alwasy activate in the post-live-migraiton callback.\n\neven if you dont suprpot neutron multiple port biding extension today.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":98,"context_line":""},{"line_number":99,"context_line":"* Inability to roll back changes to port bindings if they have been activated"},{"line_number":100,"context_line":"  on the destination host but the live migration fails during the virt driver"},{"line_number":101,"context_line":"  migration call."},{"line_number":102,"context_line":""},{"line_number":103,"context_line":"Use Cases"},{"line_number":104,"context_line":"---------"}],"source_content_type":"text/x-rst","patch_set":6,"id":"ccae4442_51f59bd2","line":101,"updated":"2026-04-01 20:48:58.000000000","message":"i dont think we will change that in this spec.\n\nactivating the portbinding is ment to only ever happen after the point of no return\n\nim not conviced we shoudl mvoe it before that point.\nwe can move it earler but if they have been activated i dont think we should attemept to revert them\n\nnot that today any tiem they are activated we will also alwasy update te isntance.host in novas db to point to the same host (the destination)\n\nthis is imporant so taht a hard reboot of the vm in error woudl resume the guest on the destination if it is possibel to do so.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":109,"context_line":"As a virt driver developer, I would like Nova to provide a generic function"},{"line_number":110,"context_line":"for activating instances’ port bindings on the destination host during live"},{"line_number":111,"context_line":"migrations, which allows the virt driver to start the network switchover"},{"line_number":112,"context_line":"process prior to the Post Live Migration stage."},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"As a virt driver developer, I would like Nova to properly roll back the"},{"line_number":115,"context_line":"changes made to the instance’s port bindings when live migrations fail during"}],"source_content_type":"text/x-rst","patch_set":6,"id":"5c3c53ea_d2cd29b9","line":112,"updated":"2026-04-01 20:48:58.000000000","message":"this is debatable if we shoudl do that but its an option\n\nmy perfernce woudl be to simply conditioner the migration completed earlier for pre-copy then we do now posibly with a config option to slect between the current and new behvior.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":114,"context_line":"As a virt driver developer, I would like Nova to properly roll back the"},{"line_number":115,"context_line":"changes made to the instance’s port bindings when live migrations fail during"},{"line_number":116,"context_line":"the virt driver migration call, so that it is safe for the driver to activate"},{"line_number":117,"context_line":"port bindings on the destination host prior to live migrations finishing."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"As a cloud operator, I would like to configure Nova to instruct the virt"},{"line_number":120,"context_line":"driver to activate port bindings on the destination host at stage *X* (differs"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1e83736c_0307c426","line":117,"updated":"2026-04-01 20:48:58.000000000","message":"nova already does in teh case where we supprot roleback and in the cases where we have not called the post_live_migration callback the will still be pointing at the\nsouce host \n\nif we have called post_live_migration we nonlonger supprot rolling back.\n\nwe docuemt this in https://docs.openstack.org/nova/2025.1/reference/live-migration.html\n\nwhen we call driver.live_migration that etier commpel succsfully and we call post_live_migration whic is the only place we activate port bindign via the api\n\nor we are in the failure path and we call rollback_live_migration and we delete the inactive port bidnigns.\n\n\ni dont think we shoudl supprot activating the porting binding on the dest in a code pat where we could still call rollback_live_migraiton\n\nso as a maintienr of the virt driver i disagree with this usecase","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":118,"context_line":""},{"line_number":119,"context_line":"As a cloud operator, I would like to configure Nova to instruct the virt"},{"line_number":120,"context_line":"driver to activate port bindings on the destination host at stage *X* (differs"},{"line_number":121,"context_line":"by drivers) to best accommodate my environment and customer needs."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Proposed change"},{"line_number":124,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"91d2046f_776cd02f","line":121,"updated":"2026-04-01 20:48:58.000000000","message":"i dont think operator shoudl have totlal freedom over this\n\nthat is leaking too much of the abstraction that nova builds over the hyperviors\n\nbut i coudl see a singel boolean flag or simialr to allow operators to choose form a set fo optiosn nova has agreed to suprpot.\n\nat the moment we have 1 such flag per/post copy\n\nfor pre-copy we coudl ahve a second flag for early or late activation\nbased on if the vm has been paused on the souce vs migration fully completed on the dest.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"6d06031c6ece2a66bd28f016fd1ccddfb63b84e9","unresolved":true,"context_lines":[{"line_number":118,"context_line":""},{"line_number":119,"context_line":"As a cloud operator, I would like to configure Nova to instruct the virt"},{"line_number":120,"context_line":"driver to activate port bindings on the destination host at stage *X* (differs"},{"line_number":121,"context_line":"by drivers) to best accommodate my environment and customer needs."},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Proposed change"},{"line_number":124,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":6,"id":"b3425bd3_8a37a13c","line":121,"in_reply_to":"91d2046f_776cd02f","updated":"2026-04-02 17:50:23.000000000","message":"Understood, to make it simple, I think it makes sense to have a bool flag (e.g., activate_port_binding_early) here to say if you want to activate ports early or late, and early or late would be determined by the virt driver.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":127,"context_line":"implementation."},{"line_number":128,"context_line":""},{"line_number":129,"context_line":"Extract all network-related code from the current live migration workflow and"},{"line_number":130,"context_line":"group them into four high-level functions. Each will do the following:"},{"line_number":131,"context_line":""},{"line_number":132,"context_line":"* `pre_network_migration`"},{"line_number":133,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"6b3e0522_000f3f1e","line":130,"updated":"2026-04-01 20:48:58.000000000","message":"-1","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":145,"context_line":"      run `migrate_network_to_destination` to activate them if not. Clean"},{"line_number":146,"context_line":"      up the stale port bindings on the source host."},{"line_number":147,"context_line":""},{"line_number":148,"context_line":"* `rollback_network_migration`"},{"line_number":149,"context_line":""},{"line_number":150,"context_line":"    * Re-activate all port bindings on the source host and delete all port"},{"line_number":151,"context_line":"      bindings on the destination host."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"Introduce a new virt lifecycle event"},{"line_number":154,"context_line":"`EVENT_LIFECYCLE_MIGRATION_NETWORK_MIGRATION` that acts as a signal for"},{"line_number":155,"context_line":"`nova-compute` to call `migrate_network_to_destination` in the lifecycle event"}],"source_content_type":"text/x-rst","patch_set":6,"id":"27cee1b0_246205cb","line":152,"range":{"start_line":148,"start_character":3,"end_line":152,"end_character":1},"updated":"2026-04-01 20:48:58.000000000","message":"honestly im -1 on this concpet in general","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":151,"context_line":"      bindings on the destination host."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"Introduce a new virt lifecycle event"},{"line_number":154,"context_line":"`EVENT_LIFECYCLE_MIGRATION_NETWORK_MIGRATION` that acts as a signal for"},{"line_number":155,"context_line":"`nova-compute` to call `migrate_network_to_destination` in the lifecycle event"},{"line_number":156,"context_line":"handler. `nova-compute` will only call `migrate_network_to_destination` when"},{"line_number":157,"context_line":"it receives `EVENT_LIFECYCLE_MIGRATION_COMPLETED` or"}],"source_content_type":"text/x-rst","patch_set":6,"id":"8d213e38_cd401847","line":154,"range":{"start_line":154,"start_character":1,"end_line":154,"end_character":44},"updated":"2026-04-01 20:48:58.000000000","message":"so thse event are hypervior specific and whiel we can ahve a new one it shoudl really be calling the exsitign post-live-migraton callback or if it was to call a new fucntion i dont think it woudl be reason to allow rollback once we have done so as there is now an inherint race window where the vms could complete the migraiton an we woudl ahve to call post-live-migrate to clean up/activate the storage.\n\n\nseparating the networking and storage is kind fo problematic without making the process much more complciated.\n\nfor example fi we were to call  migrate_network_to_destination we woudl need to ensure the comptue agent does not process EVENT_LIFECYCLE_MIGRATION_COMPLETED untile migrate_network_to_destination completes. but we shoudl not run migrate_network_to_destination syncronously on the event handler thread.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"6d06031c6ece2a66bd28f016fd1ccddfb63b84e9","unresolved":true,"context_lines":[{"line_number":151,"context_line":"      bindings on the destination host."},{"line_number":152,"context_line":""},{"line_number":153,"context_line":"Introduce a new virt lifecycle event"},{"line_number":154,"context_line":"`EVENT_LIFECYCLE_MIGRATION_NETWORK_MIGRATION` that acts as a signal for"},{"line_number":155,"context_line":"`nova-compute` to call `migrate_network_to_destination` in the lifecycle event"},{"line_number":156,"context_line":"handler. `nova-compute` will only call `migrate_network_to_destination` when"},{"line_number":157,"context_line":"it receives `EVENT_LIFECYCLE_MIGRATION_COMPLETED` or"}],"source_content_type":"text/x-rst","patch_set":6,"id":"058231c9_c19bffa9","line":154,"range":{"start_line":154,"start_character":1,"end_line":154,"end_character":44},"in_reply_to":"8d213e38_cd401847","updated":"2026-04-02 17:50:23.000000000","message":"I don\u0027t think we\u0027ll need to wait for migrate_network_to_destination to finish. IIUC, the activation is safe to do multiple times (i.e., we activate it if it\u0027s not activated, and ignore the error if it\u0027s already activated), and we do still check and activate bindings in post live migration in case the driver doesn\u0027t call it. So essentially there is no change to the current workflow, other than we may send an activation request earlier.\n\nBut storage is a fair concern. Can you elaborate more on \"activate the storage\"? IIUC, for network storage like Ceph, we don\u0027t need to \"activate\" the storage, as the connection to the storage backend from the dest VM will already be established before migration happens? Wondering if you are talking about something like bare metal storage. If that\u0027s the case, I think it would make sense to say if you are using something like this, do not enable \"activate_port_binding_early\".","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":186,"context_line":"          `VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED` for the libvirt driver)."},{"line_number":187,"context_line":"          `nova-compute` manager will capture it and call"},{"line_number":188,"context_line":"          `migrate_network_to_destination`."},{"line_number":189,"context_line":"        * Virt drivers can utilize the provided"},{"line_number":190,"context_line":"          `migrate_network_to_destination` function in"},{"line_number":191,"context_line":"          `driver.live_migration`’s parameter to activate port bindings on"},{"line_number":192,"context_line":"          destination hosts when possible."},{"line_number":193,"context_line":""},{"line_number":194,"context_line":"    * It is possible for some drivers to neither call"},{"line_number":195,"context_line":"      `migrate_network_to_destination` nor generate"}],"source_content_type":"text/x-rst","patch_set":6,"id":"84229212_b05f3b40","line":192,"range":{"start_line":189,"start_character":10,"end_line":192,"end_character":42},"updated":"2026-04-01 20:48:58.000000000","message":"whne we activate the port bidnign netowrk backend are expect to nolonger mirror traffic form the souce to the dest and to nologner deliver traffic to the source\n\nif we were to allwo recovery after that point it woudl deleya hte recovery because we would need an extra network round trip to neutron to reactivate or recreate the souce port biding vs today we gurrenty they are active on the socue untile its no logner possibel toe revert.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":206,"context_line":"      generate lifecycle events for live migrations."},{"line_number":207,"context_line":"    * Stale port bindings on the source host will be cleaned up."},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"If the live migration fails - Rollback Live Migration Stage:"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"* Call `rollback_network_migration` in case virt drivers called the"},{"line_number":212,"context_line":"  `migrate_network_to_destination` function and port bindings on the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"309453d1_5c5c39ee","line":209,"updated":"2026-04-01 20:48:58.000000000","message":"today htis never happesn after the intiall call to the hypervioer. if it acpcpet the start of the migraiont we are commited to never roolback\n\nso this is a very large change in behaviour and im not sure that is something we should do to.\n\nthis is perhaps the most contoverial part of this spec.\nas its fundamentlaly chagne the point at which the rollback is allowd fom when we call the hypervior to start the migtion to after its runnign.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"6d06031c6ece2a66bd28f016fd1ccddfb63b84e9","unresolved":true,"context_lines":[{"line_number":206,"context_line":"      generate lifecycle events for live migrations."},{"line_number":207,"context_line":"    * Stale port bindings on the source host will be cleaned up."},{"line_number":208,"context_line":""},{"line_number":209,"context_line":"If the live migration fails - Rollback Live Migration Stage:"},{"line_number":210,"context_line":""},{"line_number":211,"context_line":"* Call `rollback_network_migration` in case virt drivers called the"},{"line_number":212,"context_line":"  `migrate_network_to_destination` function and port bindings on the"}],"source_content_type":"text/x-rst","patch_set":6,"id":"2ac6444b_2ee6c189","line":209,"in_reply_to":"309453d1_5c5c39ee","updated":"2026-04-02 17:50:23.000000000","message":"I think most of the comments are related to this core idea so let\u0027s discuss here :D.\n\nI understand that currently port binding activation only happens after a migration has succeeded (i.e., post live migration) and this will cause additional latency for live migration failure cases for neutron backends like OVN. That\u0027s a very valid point, because in case of a failure, if we clean up the binding on the source side before live migration succeeds, we would have to rebind it, resulting in additional network downtime. This is not a concern now because we only do cleanup after live migration succeeds.\n\nHowever, the story will be different for drivers that do not and cannot support what OVN supports (i.e., mirror the traffic to dest VM too). If the driver operates on L3 level only, then it is impossible to have two routes to the same IP address but to different VMs coexist within the same network. Thus, for these drivers, a port activation request would really mean \"activate\" (i.e., take down the src route and bring up the dest route). And in this case, failures and rollbacks are ok for such drivers, because the benefit of doing the switch over early outweighs the drawback, as relatively speaking, failures happen less frequently.\n\nFor example, if you still recall our conversation last year, we noticed that after the VM is paused, it takes a long time (~20s, even \u003e1min sometimes) for libvirt to shut down the QEMU process on the source hyp (due to KSM and a kernel bug in THP) and emits the \"migration is done\" event. This would mean that within this ~20s period, we are doing nothing but waiting for the shutdown, even though the VM is already resumed on the destination side. I had a custom patch to direct Nova to activate port bindings as soon as the VM is paused, and we are able to reduce the downtime from ~24s to ~4s (the ~4s is a limitation on the neutron driver side, which we are working to improve). Regardless, the progress of live migration should not be blocked by cleanup tasks like this to begin with.\n\nI understand that a neutron driver is expected to set up the network connectivity on the dest side before live migration happens, but I\u0027d like to point out again that for some drivers and for some network setups, it\u0027s simply not possible, and we have to find workarounds. With that being said - maybe I wasn\u0027t being very explicit in the spec - I do not intend to alter the current behavior/workflow of how things work (esp given this might negatively impact drivers like OVN). Rather, this behavior should be made optional (default setting being not activate port binding early, like what we are doing now), and we give the operators control whether they want to do this or not (i.e., for drivers like OVN, leave it disabled, and for drivers that do not support what OVN supports, consider enabling it). In this case, we get the best of both worlds. Given OpenStack is built to support various kinds of drivers, such option should not be abstracted away from operators, as the neutron drivers function very differently in this case.\n\nNow back to the idea of rollback. As your previous bug report shows [0], it is possible for live migration to fail but the source VM will be resumed and thus port bindings should be rolled back to src. If we consider enabling the binding prior to migration succeeds (i.e., when the VM is paused on source), then we need the ability to roll it back, and we should treat port bindings as rollback-able, but only if activate_port_binding_early is true. In this way, we still persist the old workflow with activate_port_binding_early \u003d false.\n\n[0]: https://bugs.launchpad.net/nova/+bug/1788014","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e2224418e3a89dba1e5abc67b4222bbf17f6e7a0","unresolved":true,"context_lines":[{"line_number":216,"context_line":"  potentially resumed instances to function properly if there is no hard"},{"line_number":217,"context_line":"  crash."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"With this change, Nova provides flexibility for drivers to activate port"},{"line_number":220,"context_line":"bindings on the destination host when possible. Developers can introduce"},{"line_number":221,"context_line":"per-driver configurations to allow cloud operators to change when they"},{"line_number":222,"context_line":"would like to activate the port bindings depending on their environments."},{"line_number":223,"context_line":"For example, the libvirt driver can have a"},{"line_number":224,"context_line":"`libvirt.live_migration_switch_over_network_at configuration` to instruct"},{"line_number":225,"context_line":"the driver to call `migrate_network_to_destination` when instances are"},{"line_number":226,"context_line":"suspended (`VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED`), resumed"},{"line_number":227,"context_line":"(`VIR_DOMAIN_EVENT_RESUMED_MIGRATED`), live migrations have finished"},{"line_number":228,"context_line":"(`VIR_DOMAIN_JOB_COMPLETED`), or in the Post Live Migration stage."},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"Nova should also have a new stage, `network_migration` (and corresponding"},{"line_number":231,"context_line":"notifications), in the live migration workflow, which starts at the beginning"}],"source_content_type":"text/x-rst","patch_set":6,"id":"8ced01c0_8ecf2e3f","line":228,"range":{"start_line":219,"start_character":0,"end_line":228,"end_character":66},"updated":"2026-04-01 20:48:58.000000000","message":"we really dont want the behvior to vary per driver.\n\nwe want the logic in the compute manger to be driver indepenend with the only choice the drver gets to make si when is the migrtion complete enouch to tirger post_live_migration orpeations.\n\nwe can do that safely at VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED VIR_DOMAIN_EVENT_RESUMED_MIGRATED or VIR_DOMAIN_JOB_COMPLETED\n\nbut all of those shodul be considered the post_live_migraton stage","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"},{"author":{"_account_id":38560,"name":"Zhan Zhang","display_name":"Zhan","email":"zhanz1.ius@proton.me","username":"zhanz1","status":"Software Engineer @ Bloomberg"},"change_message_id":"6d06031c6ece2a66bd28f016fd1ccddfb63b84e9","unresolved":true,"context_lines":[{"line_number":216,"context_line":"  potentially resumed instances to function properly if there is no hard"},{"line_number":217,"context_line":"  crash."},{"line_number":218,"context_line":""},{"line_number":219,"context_line":"With this change, Nova provides flexibility for drivers to activate port"},{"line_number":220,"context_line":"bindings on the destination host when possible. Developers can introduce"},{"line_number":221,"context_line":"per-driver configurations to allow cloud operators to change when they"},{"line_number":222,"context_line":"would like to activate the port bindings depending on their environments."},{"line_number":223,"context_line":"For example, the libvirt driver can have a"},{"line_number":224,"context_line":"`libvirt.live_migration_switch_over_network_at configuration` to instruct"},{"line_number":225,"context_line":"the driver to call `migrate_network_to_destination` when instances are"},{"line_number":226,"context_line":"suspended (`VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED`), resumed"},{"line_number":227,"context_line":"(`VIR_DOMAIN_EVENT_RESUMED_MIGRATED`), live migrations have finished"},{"line_number":228,"context_line":"(`VIR_DOMAIN_JOB_COMPLETED`), or in the Post Live Migration stage."},{"line_number":229,"context_line":""},{"line_number":230,"context_line":"Nova should also have a new stage, `network_migration` (and corresponding"},{"line_number":231,"context_line":"notifications), in the live migration workflow, which starts at the beginning"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7dbaf3da_7ebcbb13","line":228,"range":{"start_line":219,"start_character":0,"end_line":228,"end_character":66},"in_reply_to":"8ced01c0_8ecf2e3f","updated":"2026-04-02 17:50:23.000000000","message":"Make sense, we will just have one bool flag \"activate_port_bindings_early\" and we\u0027ll let the driver decide what the earliest point it can activate port bindings is, just like how we let it decide when it should do post live migration or roll back.","commit_id":"d86ca4792c24fa6e0a287db89a2984a3dd560d04"}]}