)]}'
{"specs/xena/ovn-auxiliary-port-bridge-live-migration.rst":[{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"f10e42115a19d75a2c8a306a1ed42b70244cc9f4","unresolved":true,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Since [1]_ and [2]_, Nova is capable of plugging the port and create the"},{"line_number":20,"context_line":"interface in the destination host during the pre-live migration. But the TAP"},{"line_number":21,"context_line":"device is create by libvirt when the VM is unpaused. This is when the port"},{"line_number":22,"context_line":"interface is assigned with an OpenFlow port ID."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"When the port is created, the network backend detects the new port attached"}],"source_content_type":"text/x-rst","patch_set":3,"id":"1fab3139_bd479430","line":21,"range":{"start_line":21,"start_character":10,"end_line":21,"end_character":16},"updated":"2021-07-07 08:00:03.000000000","message":"nit: created","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"e059af833393ff5423725eef0f965c9d2f11638a","unresolved":false,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Since [1]_ and [2]_, Nova is capable of plugging the port and create the"},{"line_number":20,"context_line":"interface in the destination host during the pre-live migration. But the TAP"},{"line_number":21,"context_line":"device is create by libvirt when the VM is unpaused. This is when the port"},{"line_number":22,"context_line":"interface is assigned with an OpenFlow port ID."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"When the port is created, the network backend detects the new port attached"}],"source_content_type":"text/x-rst","patch_set":3,"id":"5cb44536_b76ee2da","line":21,"range":{"start_line":21,"start_character":10,"end_line":21,"end_character":16},"in_reply_to":"1fab3139_bd479430","updated":"2021-07-08 10:20:22.000000000","message":"Done","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"bb07dd445c8c76e22ac3b7bc5d922fef6170b0e5","unresolved":true,"context_lines":[{"line_number":32,"context_line":"ID (``interface.ofport``) assigned when the TAP interface is created."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Proposed Change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"This spec proposes to create an intermediate OVS bridge between the integration"}],"source_content_type":"text/x-rst","patch_set":3,"id":"cce25c43_ca3c2a17","line":35,"range":{"start_line":35,"start_character":0,"end_line":35,"end_character":15},"updated":"2021-07-07 08:50:47.000000000","message":"I remember that there is multiple port binding for ML2 [1], did those changes [2] fixed the live migration issue for ML2 OVS? can OVN use such mechanism to overcome this? \n\n[1] https://review.opendev.org/c/openstack/neutron/+/414251\n[2] https://review.opendev.org/q/topic:%22bp%252Flive-migration-portbinding%22+(status:open%20OR%20status:merged)","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"65fd9bb1caca334d08665ab1956fc209a7a6dada","unresolved":true,"context_lines":[{"line_number":32,"context_line":"ID (``interface.ofport``) assigned when the TAP interface is created."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Proposed Change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"This spec proposes to create an intermediate OVS bridge between the integration"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2dc76706_bfb3cd78","line":35,"range":{"start_line":35,"start_character":0,"end_line":35,"end_character":15},"in_reply_to":"01f81984_627b5040","updated":"2021-07-08 11:31:42.000000000","message":"rodolfo is correct multiple port binding is unrelated to this and cannot be used to fix this.\n\nregarding ml2/ovs this feature with 0 changes at least form the os-vif/nova side could be used when using ml2/ovs with the openflow firewall. it had the same proablem but we recently weakend the requirement for the ofport-id in the neutron l2 agent so it will tag the the interface before the ofport id is set which given ml2/ovs uses the normal action is suffent to prevent the mac learning frams form being lost.\n\nhttps://review.opendev.org/c/openstack/neutron/+/640258\nhttps://review.opendev.org/c/openstack/neutron/+/753314\n\nwhich was required to fix this issue in ml2/ovs\nhttps://review.opendev.org/c/openstack/neutron/+/766277\n\nif we had added these per port bridges then we coudl have avoided the need for the first 2 patches but we did not od that since we tought it was too invasive give there were other options avaiable.\n\nfor ovn i do not know of any other way to address the packet loss issue other then modifying ovn too also not require the ofport id","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"36153161160458b2d923875d4b484dfd2282ce93","unresolved":true,"context_lines":[{"line_number":32,"context_line":"ID (``interface.ofport``) assigned when the TAP interface is created."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Proposed Change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"This spec proposes to create an intermediate OVS bridge between the integration"}],"source_content_type":"text/x-rst","patch_set":3,"id":"7eea5632_21f4693f","line":35,"range":{"start_line":35,"start_character":0,"end_line":35,"end_character":15},"in_reply_to":"2dc76706_bfb3cd78","updated":"2021-07-12 03:16:56.000000000","message":"Thank you guys for the detailed comments. 😊\nIf ofport is the critical data, for ML2 OVS, I have another idea to do the flow installation without adding new ovs-bridges and patch ports.\n\n1. Nova starts live-migration.\n2. In the pre-live-migration on destination, nova request neutron to allocate a ofport number.\n3. Neutron-server accept this request and send to destanation host\u0027s ovs-agent.\n4. A valid ofport allocated and saved to port binding profile, then reponse back to Nova.\n5. Nova tries to call neutron to bind (multiple bindings) this port to destination host.\n6. Neutron ovs-agent uses the binding profiles ofport number to install flows.\n7. Nova (libvirt) unpaused the VM and plug the VIF  with the ofport number (flows had been set in 6.)\n\nFor 2., Neutron ovs-agent may need to do some refactor of ofport management.\nFor 6., Neutron ovs-agent needs to add new methods to install flows beyond the OVS-DB monitoring mechanism.\nFor 7., lib osvif needs to plug ovs-vif with ofport param.\n\nYep, looks a bit complicated. But for 2. and 6. are popular in large-scale OVS (SDN) controller implementation practice. Flows installation and ofport allocation are handled by controller. \n\nI\u0027m not sure if there will be some problems with too many \"hybrid\" style devices in OVS. At least, we gonna to say goodbye to iptables_hybrid drivers, we should not introduce a new one.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bb7e87348e6f674450ec864846a615e8e5e3674f","unresolved":true,"context_lines":[{"line_number":32,"context_line":"ID (``interface.ofport``) assigned when the TAP interface is created."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Proposed Change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"This spec proposes to create an intermediate OVS bridge between the integration"}],"source_content_type":"text/x-rst","patch_set":3,"id":"636087b0_38ec77c3","line":35,"range":{"start_line":35,"start_character":0,"end_line":35,"end_character":15},"in_reply_to":"4bfaa54f_1b487e8e","updated":"2021-07-14 11:30:30.000000000","message":"im a hard -1 to adding any additional calls to neutron for ofport allocations.\nif it was done transparently via existing calls such as the creation of the dest port binding that might be accptable but i do not like this alternitive design approch.\n\ni will point out that until recently it was not possible to set the requested_ofportid as libvirt cannot program that\nso this would not have work at all when libvirt was adding the port to ovs.\nnow that os-vif is adding the port we coudl sett the requested_ofportid but we are not guarenteed that it will get port id. if a port with a given id is not presnet on the data path im not sure if its valid to add an openflow rule that refernces that id. assuming ovs does not reject the flow as an error  presumable it would drop all packet setnt to the ofport_id until the tap was created but if the tap was to get a differnt port id it could be problematic.\n\nwe would also have to modify ml2/odl, ml2/onos and any other third party ovs ml2 driver in addtion to the in tree ml2/ovs and ml2/ovn dirvers to make this work.\n\nfor what its worth i have wanted to use per por bidges for 4+ years so i dont think this is  problematic to introduce it now.\nusing per port bridges greatly simplifes the openflow rules and would have removed the need for much of the complexity of the current table structre used in ml2 ovs.\n\nrodolfo is correct that the current scope of this spec is just the ml2 changes within neutron for ovn. doing what you describe would require much larger change across multiple ml2 dirver unless you where to add ofport id management above the driver level which seams wrong as it would not apply to non ovs ml2 drivers.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"bd348abc889077ec869e31fc5937baa9a9ff506b","unresolved":true,"context_lines":[{"line_number":32,"context_line":"ID (``interface.ofport``) assigned when the TAP interface is created."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Proposed Change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"This spec proposes to create an intermediate OVS bridge between the integration"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4bfaa54f_1b487e8e","line":35,"range":{"start_line":35,"start_character":0,"end_line":35,"end_character":15},"in_reply_to":"7eea5632_21f4693f","updated":"2021-07-14 10:30:40.000000000","message":"First of all, I would like to remark that the scope of this feature is OVN only. It could be extended to OVS easily (the os-vif implementation is shared between both backends), but is not covered here.\n\nThe problem of the interface ofport is not assigning a deterministic ofport number but how OVS provides it. When os-vif creates a port with the corresponding interface, if the TAP port is not present (that is created by libvirt), the interface ofport given is -1 [1].\n\nOVN will use this value interface.ofport, not interface.ofport_request, to write the OF rules in OVS. If the ofport is -1 (invalid), the port won\u0027t be provisioned in OVN.\n\nThis is what this spec and the os-vif patch specifically want to solve, that is to provide a integration bridge port with a valid ofport BEFORE creating the VM TAP port that is created by libvirt when the VM is unpaused in the destination host. At this moment, OVN should have configured the local OVS to provide communication to this port.\n\n[1]https://paste.opendev.org/show/807459/","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"e059af833393ff5423725eef0f965c9d2f11638a","unresolved":true,"context_lines":[{"line_number":32,"context_line":"ID (``interface.ofport``) assigned when the TAP interface is created."},{"line_number":33,"context_line":""},{"line_number":34,"context_line":""},{"line_number":35,"context_line":"Proposed Change"},{"line_number":36,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":37,"context_line":""},{"line_number":38,"context_line":"This spec proposes to create an intermediate OVS bridge between the integration"}],"source_content_type":"text/x-rst","patch_set":3,"id":"01f81984_627b5040","line":35,"range":{"start_line":35,"start_character":0,"end_line":35,"end_character":15},"in_reply_to":"cce25c43_ca3c2a17","updated":"2021-07-08 10:20:22.000000000","message":"This is not a problem of the logic in Neutron, that we are currently using, but how the backend detects a new port, binds it and configures the underlying OF rules to accept traffic from it.\n\nActually this feature, with minimal changes, could be used in OVS. The goal of this feature is to provide to the backend a port with a valid ofport that will be used to set the proper OF rules, regardless of the TAP device creation, that is done when libvirt unpauses the VM.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"f10e42115a19d75a2c8a306a1ed42b70244cc9f4","unresolved":true,"context_lines":[{"line_number":43,"context_line":"OVS hybrid plugging, but with an OVS bridge in between."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"The advantage of this approach is that the integration bridge port, in this"},{"line_number":46,"context_line":"case the patch port, that created during the pre-live migration process, has"},{"line_number":47,"context_line":"a valid OpenFlow port ID (``interface.ofport``), needed to provide the correct"},{"line_number":48,"context_line":"OpenFlow rules in the integration bridge."},{"line_number":49,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5d626b49_2471992e","line":46,"range":{"start_line":46,"start_character":21,"end_line":46,"end_character":26},"updated":"2021-07-07 08:00:03.000000000","message":"nit: that is","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"e059af833393ff5423725eef0f965c9d2f11638a","unresolved":false,"context_lines":[{"line_number":43,"context_line":"OVS hybrid plugging, but with an OVS bridge in between."},{"line_number":44,"context_line":""},{"line_number":45,"context_line":"The advantage of this approach is that the integration bridge port, in this"},{"line_number":46,"context_line":"case the patch port, that created during the pre-live migration process, has"},{"line_number":47,"context_line":"a valid OpenFlow port ID (``interface.ofport``), needed to provide the correct"},{"line_number":48,"context_line":"OpenFlow rules in the integration bridge."},{"line_number":49,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3153e9af_1400e950","line":46,"range":{"start_line":46,"start_character":21,"end_line":46,"end_character":26},"in_reply_to":"5d626b49_2471992e","updated":"2021-07-08 10:20:22.000000000","message":"Done","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"f10e42115a19d75a2c8a306a1ed42b70244cc9f4","unresolved":true,"context_lines":[{"line_number":48,"context_line":"OpenFlow rules in the integration bridge."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"When the virtual machine is unpaused, the backend is ready to continue"},{"line_number":51,"context_line":"transmitting the port packets."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":3,"id":"ea2689c1_bc96ca34","line":51,"updated":"2021-07-07 08:00:03.000000000","message":"I have a doubt here: let\u0027s imagine situation when vm is still running on src host and it\u0027s also prepared by nova on dest host. Now OVN will see patch port in integration bridge and will configure everything for this port. And now for some time, before nova will actually move vm from src to dest node, OVN will have 2 paths configured for the same port. Wouldn\u0027t that be a problem?","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"e059af833393ff5423725eef0f965c9d2f11638a","unresolved":true,"context_lines":[{"line_number":48,"context_line":"OpenFlow rules in the integration bridge."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"When the virtual machine is unpaused, the backend is ready to continue"},{"line_number":51,"context_line":"transmitting the port packets."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e8622a12_72b4d14a","line":51,"in_reply_to":"2cabd659_bb43c012","updated":"2021-07-08 10:20:22.000000000","message":"The process for Neutron/OVN is the same as we currently have: when the destination port is plugged and detected by ovn-controller, the OVN SB port binding register sets the new chassis (the destination chassis).\n\nBut with this feature, as commented, we have a port with a valid interface ofport, that will be used to properly configure the backend (the OF rules, depending on this ofport).\n\nAs Sean commented, when the port is plugged during the pre-live migration process. Then Nova commands libvirt to start the migration, using the \"live_migration_permit_post_copy\" flag [1]. This process should be quick (some times it is not) to unpause the destination VM as fast as possible.\n\nDuring this guess memory copy, the port is already bound to the destination chassis, with and without this feature. What we need is to minimize the copy time but that will depend on the VM load or the memory configuration. As commented by Sean via IRC, migrating a VM with hugepages implies to re-copy each 1GB page used by the VM during the copy process; VMs with high network throughput will have the same problem.\n\n[1]https://docs.openstack.org/nova/pike/admin/live-migration-usage.html","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"cbf6ec2a6272528cb8a9b2adfed2dca942880cd1","unresolved":true,"context_lines":[{"line_number":48,"context_line":"OpenFlow rules in the integration bridge."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"When the virtual machine is unpaused, the backend is ready to continue"},{"line_number":51,"context_line":"transmitting the port packets."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":3,"id":"eeb28032_473acd4b","line":51,"in_reply_to":"e8622a12_72b4d14a","updated":"2021-07-21 09:43:38.000000000","message":"Ok. It sounds like there shouldn\u0027t be that problem which I was thinking off as OVN can somehow handle that. But still I see a difference between what is now and what will be with that change: now port on one of the nodes (dest) has invalid ofport and IMHO it may be working fine because of that. With Your change we will have completely valid ports, with valid ofports on 2 nodes.\nI never played with post-copy live migration mode so I don\u0027t know if/how it works now.\nBut in general if You are saying that it will work ok, I\u0027m fine with that :)","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"e85c4ca89a05938bbe1c4cfd536dd847cd910b02","unresolved":true,"context_lines":[{"line_number":48,"context_line":"OpenFlow rules in the integration bridge."},{"line_number":49,"context_line":""},{"line_number":50,"context_line":"When the virtual machine is unpaused, the backend is ready to continue"},{"line_number":51,"context_line":"transmitting the port packets."},{"line_number":52,"context_line":""},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":3,"id":"2cabd659_bb43c012","line":51,"in_reply_to":"ea2689c1_bc96ca34","updated":"2021-07-07 09:36:36.000000000","message":"the port already exits on the source and dest for a period of time today.\nit is a hard requirement for ovn to handle this condition otherwise we cannot support live migration with ovn at all.\n\nespecially in post copy mode where we switch execution to the dest before we have copied all the guest memory as that will today already extend the time where the port exits on both hosts\n\ni do understand the concern but if ovn does not support this today its already a bug in ovn.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"bb7e87348e6f674450ec864846a615e8e5e3674f","unresolved":true,"context_lines":[{"line_number":59,"context_line":"and deletion will be done during the plug and unplug processes [3]_, as in OVS"},{"line_number":60,"context_line":"hybrid plug strategy."},{"line_number":61,"context_line":""},{"line_number":62,"context_line":"The proposed architecture and naming is the following one, implemented in"},{"line_number":63,"context_line":"[4]_:"},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"::"}],"source_content_type":"text/x-rst","patch_set":3,"id":"cd571adf_b212cfcf","line":62,"range":{"start_line":62,"start_character":0,"end_line":62,"end_character":73},"updated":"2021-07-14 11:30:30.000000000","message":"nit: technically the details of the os-vif changes are out of scope of this spec\nThis is provided for reference for understanding the other ml2/ovn changes that are covered by this spec.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"f10e42115a19d75a2c8a306a1ed42b70244cc9f4","unresolved":true,"context_lines":[{"line_number":96,"context_line":"``interface.external_ids\u003d{iface-id: port_id}``. The ovn-controller will detect"},{"line_number":97,"context_line":"this new port and assign to OVN SB Port Binding the corresponding chassis."},{"line_number":98,"context_line":"The ``interface.external_ids`` information is added by ``os-vif`` during the"},{"line_number":99,"context_line":"port plug process [4]_, called by Nova."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Nova - Neutron events"}],"source_content_type":"text/x-rst","patch_set":3,"id":"c06d080b_9ee504b6","line":99,"updated":"2021-07-07 08:00:03.000000000","message":"All of that is described in context of the OVN backend. Currently both OVN and ML2/OVS are using same vif_type so ports are plugged by os-vif in same way (of course without hybrid_plug in case of ML2/OVS). Will this new connection be also done for ML2/OVS case or will we change vif_type in case of ML2/OVN?","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"65fd9bb1caca334d08665ab1956fc209a7a6dada","unresolved":true,"context_lines":[{"line_number":96,"context_line":"``interface.external_ids\u003d{iface-id: port_id}``. The ovn-controller will detect"},{"line_number":97,"context_line":"this new port and assign to OVN SB Port Binding the corresponding chassis."},{"line_number":98,"context_line":"The ``interface.external_ids`` information is added by ``os-vif`` during the"},{"line_number":99,"context_line":"port plug process [4]_, called by Nova."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Nova - Neutron events"}],"source_content_type":"text/x-rst","patch_set":3,"id":"b35cc4a0_b888243e","line":99,"in_reply_to":"aeaa3998_b47b2e7b","updated":"2021-07-08 11:31:42.000000000","message":"we recently change ml2/ovs ot not strictly requrie the ofport so the improvemtn for ml2/ovs should be minimal but it should not regress it.\nby default this will initally be off so i can backport the os-vif patch and allow operator to opt in to it\nbut i will be wring another cahnge to os-vif that will pass the ml2 driver that bound the port to os-vif\nthat will require an os-vif object change but once done that will allow us to enable this automatically for ovn or other backend that would benifit such as potentailly ml2/ovs with ovs firewall although that is still tbd if it will imporve perfromacne or not.\n\n\nin terms of vif_type the vif_type descib the network backend not the neutron backedn\nml2/ovs ml2/ovn, ml2/odl and ml2/onos i belvie all use vif_type ovs since in all cases nova/os-vif\nis adding a port to ovs and in the case fo libvirt they are all generated as tap devices.\n\nthe vif types are ment to be shared between ml2 implemantions so that you can write an out of tree implation and pass any vif type nova already know about and in theory you can use it.\n\nthe same is true of the vnic types they are intended to be shared across ml2 drivers. (or core plugins technially)\n\nso it would be incorrect ot have a ovn vif_type.\n\n@slawek\nwe can tell what the ml2 driver is now from https://specs.openstack.org/openstack/neutron-specs/specs/train/port-binding-extended-information.html\n\nthat proposal orginally also included telling nova when the event would be sent but it was droped as we did not agree on the format/names of the time when the events woudl be sent.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"cbf6ec2a6272528cb8a9b2adfed2dca942880cd1","unresolved":true,"context_lines":[{"line_number":96,"context_line":"``interface.external_ids\u003d{iface-id: port_id}``. The ovn-controller will detect"},{"line_number":97,"context_line":"this new port and assign to OVN SB Port Binding the corresponding chassis."},{"line_number":98,"context_line":"The ``interface.external_ids`` information is added by ``os-vif`` during the"},{"line_number":99,"context_line":"port plug process [4]_, called by Nova."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Nova - Neutron events"}],"source_content_type":"text/x-rst","patch_set":3,"id":"4c24f6e5_ec155936","line":99,"in_reply_to":"b35cc4a0_b888243e","updated":"2021-07-21 09:43:38.000000000","message":"thx Sean for explanation. So on os-vif\u0027s side it will be distinguished based on  \"bound_drivers\" info from the port binding.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"bb07dd445c8c76e22ac3b7bc5d922fef6170b0e5","unresolved":true,"context_lines":[{"line_number":96,"context_line":"``interface.external_ids\u003d{iface-id: port_id}``. The ovn-controller will detect"},{"line_number":97,"context_line":"this new port and assign to OVN SB Port Binding the corresponding chassis."},{"line_number":98,"context_line":"The ``interface.external_ids`` information is added by ``os-vif`` during the"},{"line_number":99,"context_line":"port plug process [4]_, called by Nova."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Nova - Neutron events"}],"source_content_type":"text/x-rst","patch_set":3,"id":"d74f6c1a_914aaa21","line":99,"in_reply_to":"c06d080b_9ee504b6","updated":"2021-07-07 08:50:47.000000000","message":"ML2 OVS has multiple port binding [1][2], so this proposal here should be for OVN only?\n\n[1] https://review.opendev.org/c/openstack/neutron/+/414251\n[2] https://review.opendev.org/q/topic:%22bp%252Flive-migration-portbinding%22+(status:open%20OR%20status:merged)","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"e059af833393ff5423725eef0f965c9d2f11638a","unresolved":true,"context_lines":[{"line_number":96,"context_line":"``interface.external_ids\u003d{iface-id: port_id}``. The ovn-controller will detect"},{"line_number":97,"context_line":"this new port and assign to OVN SB Port Binding the corresponding chassis."},{"line_number":98,"context_line":"The ``interface.external_ids`` information is added by ``os-vif`` during the"},{"line_number":99,"context_line":"port plug process [4]_, called by Nova."},{"line_number":100,"context_line":""},{"line_number":101,"context_line":""},{"line_number":102,"context_line":"Nova - Neutron events"}],"source_content_type":"text/x-rst","patch_set":3,"id":"aeaa3998_b47b2e7b","line":99,"in_reply_to":"d74f6c1a_914aaa21","updated":"2021-07-08 10:20:22.000000000","message":"@Slawek, the VIF type is the same for OVN and OVS because the underlying backend is the same for both. The port creation is the same for both and the problem we currently have in OVN is also present in OVS.\n\nI would like to set the scope of this spec only to OVN, but this feature, with a minimum set of changes, could also improve the live migration performance in OVS for the same reason explained here. The destination host OVS could be ready to transmit through this port once is plugged. That will imply to change the vif-plugged events and inform about this to Nova (same reasons as described here).\n\n@Liu, the multiple port binding feature is used for live migration but the VIF port is the same. Because there are no reasons to create a new VIF type, I\u0027m proposing to add this vif_details flag. For OVS hybrid plugin, os-vif (and Nova) have this information and use it to create the intermediate linux bridge. But in this case we need to inform Nova that Neutron has changed the vif-plugged event emission.\n\nI\u0027m overloading the vif-details dictionary with extra information for Nova but not changing the VIF type.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":9531,"name":"liuyulong","display_name":"LIU Yulong","email":"i@liuyulong.me","username":"LIU-Yulong"},"change_message_id":"bb07dd445c8c76e22ac3b7bc5d922fef6170b0e5","unresolved":true,"context_lines":[{"line_number":171,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":172,"context_line":"commented in the previous section."},{"line_number":173,"context_line":""},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"Testing"},{"line_number":176,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"7ed7dd98_ebf698aa","line":174,"updated":"2021-07-07 08:50:47.000000000","message":"What about the effect of hardware offload (smart-NIC flows offload)?","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"e059af833393ff5423725eef0f965c9d2f11638a","unresolved":true,"context_lines":[{"line_number":171,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":172,"context_line":"commented in the previous section."},{"line_number":173,"context_line":""},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"Testing"},{"line_number":176,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"cdb28427_3c625e86","line":174,"in_reply_to":"7ed7dd98_ebf698aa","updated":"2021-07-08 10:20:22.000000000","message":"As commented in \"Performance\" section, the datapath is the same with and without this bridge.\n\nHowever because the port plug is different in os-vif (how the port representor is created and plugged), the code path should be changed too. This is not considered in this spec.","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"65fd9bb1caca334d08665ab1956fc209a7a6dada","unresolved":true,"context_lines":[{"line_number":171,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":172,"context_line":"commented in the previous section."},{"line_number":173,"context_line":""},{"line_number":174,"context_line":""},{"line_number":175,"context_line":"Testing"},{"line_number":176,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"08ae7fb5_9caafe76","line":174,"in_reply_to":"cdb28427_3c625e86","updated":"2021-07-08 11:31:42.000000000","message":"for hardware offload ovs we are adding the vf represeter netdev directly to ovs so it will have and ofport\nthe current os-vif implemeation is only for vnic_type normal\n\ni will likely add vnic_type vhost-user at some point but it is not requried for hardware offloaded ovs with vnic_types direct","commit_id":"ac8bcebeafc28a6b79f82a4dd28e6f81a840e28b"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"210881f34eb455c288f8b9777c231917a62c4ab6","unresolved":true,"context_lines":[{"line_number":52,"context_line":"a valid OpenFlow port ID (``interface.ofport``), needed to provide the correct"},{"line_number":53,"context_line":"OpenFlow rules in the integration bridge."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"After the port is plugged, Nova commands to libvirt to copy the guess memory"},{"line_number":56,"context_line":"to the destination host. If \"live_migration_permit_post_copy\" is used [3]_,"},{"line_number":57,"context_line":"the virtual machine on the destination host will be activated before all its"},{"line_number":58,"context_line":"memory has been copied. However there is a period of time where the port"}],"source_content_type":"text/x-rst","patch_set":4,"id":"23792eec_024d9564","line":55,"range":{"start_line":55,"start_character":64,"end_line":55,"end_character":69},"updated":"2021-08-19 10:51:24.000000000","message":"guest?","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"ddf5c25598fd58f95a1a65fac295b74051a98626","unresolved":false,"context_lines":[{"line_number":52,"context_line":"a valid OpenFlow port ID (``interface.ofport``), needed to provide the correct"},{"line_number":53,"context_line":"OpenFlow rules in the integration bridge."},{"line_number":54,"context_line":""},{"line_number":55,"context_line":"After the port is plugged, Nova commands to libvirt to copy the guess memory"},{"line_number":56,"context_line":"to the destination host. If \"live_migration_permit_post_copy\" is used [3]_,"},{"line_number":57,"context_line":"the virtual machine on the destination host will be activated before all its"},{"line_number":58,"context_line":"memory has been copied. However there is a period of time where the port"}],"source_content_type":"text/x-rst","patch_set":4,"id":"f85a8c5c_a36b470b","line":55,"range":{"start_line":55,"start_character":64,"end_line":55,"end_character":69},"in_reply_to":"23792eec_024d9564","updated":"2021-08-24 08:33:33.000000000","message":"Done","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"210881f34eb455c288f8b9777c231917a62c4ab6","unresolved":true,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Implementation"},{"line_number":68,"context_line":"--------------"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The VIF plug and unplug process is executed by Nova, using the different"},{"line_number":71,"context_line":"backend implementations provided by ``os-vif`` library. The bridge creation"},{"line_number":72,"context_line":"and deletion will be done during the plug and unplug processes [4]_, as in OVS"}],"source_content_type":"text/x-rst","patch_set":4,"id":"43dd9ad0_0ce1274a","line":69,"updated":"2021-08-19 10:51:24.000000000","message":"This proposal is specific to the OVN backend as mentioned above.\nDo you add a new mode to os-vif?\n\nWhat I am not sure is whether it affects ML2/OVS backend or not.\nIt is already discussed in comments but I think it is better to mention it somewhere.","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"ddf5c25598fd58f95a1a65fac295b74051a98626","unresolved":true,"context_lines":[{"line_number":66,"context_line":""},{"line_number":67,"context_line":"Implementation"},{"line_number":68,"context_line":"--------------"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"The VIF plug and unplug process is executed by Nova, using the different"},{"line_number":71,"context_line":"backend implementations provided by ``os-vif`` library. The bridge creation"},{"line_number":72,"context_line":"and deletion will be done during the plug and unplug processes [4]_, as in OVS"}],"source_content_type":"text/x-rst","patch_set":4,"id":"7cf0f90c_52ba78fe","line":69,"in_reply_to":"43dd9ad0_0ce1274a","updated":"2021-08-24 08:33:33.000000000","message":"OVS and OVN (kernel mode) are identical os-vif ports. There is no difference between both backends.\n\nThat will help OVS in a future but this is out of scope here. I\u0027ll add a reference here.","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"d89b9713b113f8b807bbae3ee4132053a55e1c8e","unresolved":true,"context_lines":[{"line_number":116,"context_line":"---------------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Nova and Neutron have a mechanism to communicate the state of the VIFs [6]_."},{"line_number":119,"context_line":"This is a unidirectional API the allows Neutron to inform Nova when a VIF has"},{"line_number":120,"context_line":"been plugged or unplugged. Nova expects from Neutron a ``network-vif-plugged``"},{"line_number":121,"context_line":"event when the port has been bound or plugged. Depending on the backend, Nova"},{"line_number":122,"context_line":"will expect a ``network-vif-plugged`` when the port has been bound or when"}],"source_content_type":"text/x-rst","patch_set":4,"id":"133de809_d336c12d","line":119,"range":{"start_line":119,"start_character":29,"end_line":119,"end_character":32},"updated":"2021-08-20 10:41:05.000000000","message":"nit: that","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"ddf5c25598fd58f95a1a65fac295b74051a98626","unresolved":false,"context_lines":[{"line_number":116,"context_line":"---------------------"},{"line_number":117,"context_line":""},{"line_number":118,"context_line":"Nova and Neutron have a mechanism to communicate the state of the VIFs [6]_."},{"line_number":119,"context_line":"This is a unidirectional API the allows Neutron to inform Nova when a VIF has"},{"line_number":120,"context_line":"been plugged or unplugged. Nova expects from Neutron a ``network-vif-plugged``"},{"line_number":121,"context_line":"event when the port has been bound or plugged. Depending on the backend, Nova"},{"line_number":122,"context_line":"will expect a ``network-vif-plugged`` when the port has been bound or when"}],"source_content_type":"text/x-rst","patch_set":4,"id":"767d072d_5f9a4a2e","line":119,"range":{"start_line":119,"start_character":29,"end_line":119,"end_character":32},"in_reply_to":"133de809_d336c12d","updated":"2021-08-24 08:33:33.000000000","message":"Done","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"210881f34eb455c288f8b9777c231917a62c4ab6","unresolved":true,"context_lines":[{"line_number":183,"context_line":"bridges), each port plumber bridge will be connected to the integration bridge"},{"line_number":184,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":185,"context_line":"commented in the previous section."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Testing"},{"line_number":189,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3af65e48_526bceb1","line":186,"updated":"2021-08-19 10:51:24.000000000","message":"It is better to mention the upgrade impact. This proposal changes the VIF plugging model for OVN. In OVN deployments deployed before this feature, VM tap ports are directly plugged into the integration bridge. I would like see the following points (related to the upgrade):\n\n- The new os-vif code should handle VIFs deployed before this feature.\n- How does the live migration process handle VM ports before this feature?","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"ddf5c25598fd58f95a1a65fac295b74051a98626","unresolved":true,"context_lines":[{"line_number":183,"context_line":"bridges), each port plumber bridge will be connected to the integration bridge"},{"line_number":184,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":185,"context_line":"commented in the previous section."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Testing"},{"line_number":189,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"f62b7059_91b5a5a3","line":186,"in_reply_to":"3af65e48_526bceb1","updated":"2021-08-24 08:33:33.000000000","message":"Right, new ports will use the new VIF plugging model. Actually with the new os-vif config option in place [1], tap ports directly plugged into the int-br won\u0027t be handled properly.\n\nThis new option should be used in an empty compute node in order to move the VMs to this node.\n\nThe explanation about how live migration was done before is done in the problem description. This is actually what we want to change.\n\n[1]https://review.opendev.org/c/openstack/os-vif/+/798055/13/vif_plug_ovs/ovs.py#100","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"a178c07def9933333c93d261ec0b66bc3f85f90f","unresolved":true,"context_lines":[{"line_number":183,"context_line":"bridges), each port plumber bridge will be connected to the integration bridge"},{"line_number":184,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":185,"context_line":"commented in the previous section."},{"line_number":186,"context_line":""},{"line_number":187,"context_line":""},{"line_number":188,"context_line":"Testing"},{"line_number":189,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":4,"id":"de1faace_2f273b97","line":186,"in_reply_to":"f62b7059_91b5a5a3","updated":"2021-08-24 11:19:43.000000000","message":"just like wwith changing form iptable to the ovs firewall the intended way to adopt per-port bridges is to drain a host of workloads, enable per port bridge then live migrate workloads to that host. you then repat that with batches of host until all your cloud is migrated to the new model.\n\ncold migration, reisze and shelve/unshelve will also work but they are more expensive operations then live migrate.","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"210881f34eb455c288f8b9777c231917a62c4ab6","unresolved":true,"context_lines":[{"line_number":222,"context_line":".. [2] https://review.opendev.org/c/openstack/nova/+/797428"},{"line_number":223,"context_line":".. [3] https://docs.openstack.org/nova/pike/admin/live-migration-usage.html"},{"line_number":224,"context_line":".. [4] https://github.com/openstack/os-vif/blob/e93736711920afe64a850f564dddefbd704975cd/vif_plug_ovs/ovs.py"},{"line_number":225,"context_line":".. [5] https://review.opendev.org/c/openstack/os-vif/+/798038"},{"line_number":226,"context_line":".. [6] https://wiki.openstack.org/wiki/Nova/ExternalEventAPI"},{"line_number":227,"context_line":".. [7] https://github.com/openstack/nova/blob/e7a7fd51d12d045ff134d55a4a1749c1feee0386/nova/network/model.py#L464-L481"},{"line_number":228,"context_line":".. [8] https://github.com/openstack/neutron/blob/13e96bf6bd740a09283d9e2849fc2b6adbbf29e3/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py#L796-L815"}],"source_content_type":"text/x-rst","patch_set":4,"id":"afea5185_5c4da133","line":225,"range":{"start_line":225,"start_character":7,"end_line":225,"end_character":61},"updated":"2021-08-19 10:51:24.000000000","message":"Is this the correct link? The link is a patch which updated the os-vif CI, so I am confused.","commit_id":"6fb23cf02eff169f2a7d971743bc6ca0dab19689"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":40,"context_line":"considering ``os_vif.objects.vif.VIFOpenVSwitch`` VIF types within the related"},{"line_number":41,"context_line":"network backend."},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"This spec proposes to create an intermediate OVS bridge between the integration"},{"line_number":44,"context_line":"bridge and the virtual machine tap interface. This OVS bridge will be connected"},{"line_number":45,"context_line":"to the integration bridge with a patch port. The TAP interface will be plugged"},{"line_number":46,"context_line":"into the intermediate bridge when the virtual machine is created or unpaused"},{"line_number":47,"context_line":"(that happens during the live migration). This architecture is very similar to"}],"source_content_type":"text/x-rst","patch_set":5,"id":"706dc496_fd7f7122","line":44,"range":{"start_line":43,"start_character":0,"end_line":44,"end_character":45},"updated":"2021-08-24 12:21:05.000000000","message":"nit this is really out of scope of this spec the spec is ment to be covering the changes to the way ovn sends events to nova to indicate the port is plugged.\n\nmoving to the per prot bridges is more a depency that is required to enable ovn to wire up the port in pre live migration then a proposed part of the spec.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":57,"context_line":"the virtual machine on the destination host will be activated before all its"},{"line_number":58,"context_line":"memory has been copied. However there is a period of time where the port"},{"line_number":59,"context_line":"is bound to the destination host and the virtual machine is still running on"},{"line_number":60,"context_line":"the source host. During this period of time, the virtual machine won\u0027t be"},{"line_number":61,"context_line":"able to communicate, same as without this feature."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"When the virtual machine is unpaused in the destination host, the OVN"},{"line_number":64,"context_line":"backend is ready to immediately continue transmitting packets from the guess."}],"source_content_type":"text/x-rst","patch_set":5,"id":"8cc00b69_0698ad88","line":61,"range":{"start_line":60,"start_character":17,"end_line":61,"end_character":50},"updated":"2021-08-24 12:21:05.000000000","message":"this is specfic to ovn, with ml2 ovs it would be abel to comunicate.\n\nthis period extend form the time that the vm start on the dest until we activate teh port binding on the dest.\n\nthe port binding is always activated on the dest after the vm starts running on the destination and we cannot activate it earlier then we do today without extending the time that the vm cant comunicate. we are already minimising this interval as best as we can within the limitations of the what we can do with libvirt.\n\nultimatly this need too be fixed in ovn as ovn need the capablity to support havign a port bound on 2 chassis at the same time or it can never support lossless or rather minimal packet loss live migration.\n\nthe issue if its not clear in ovn is that it cannot direct packets to the dest host until we update the port bining to point to it so all packets destinded for the vm will be sent to the srouce node\nbut the vm on the source node will not be able to recive them once we enter the post copy phase and excution start on the dest.\n\nfor non post copy migration this work ok for the most part because the vm runs on the sorce until all its memory is copied then its very breifly paused while the dest resumes and is quickly deleted leaving the port only presnet on the dest host. but there is still a period of time untile we update the neutron port bindings and activate the dest host where packets can still be sent to the source node where they will never be recived.\n\n\nanyway this is out of scope of this spec but to fully achive minimal packet loss ovn will have to be modifeid to handel live migration more intelegently then it does today.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"34abae619afcaea2e5d018255707808d81fea6b2","unresolved":true,"context_lines":[{"line_number":57,"context_line":"the virtual machine on the destination host will be activated before all its"},{"line_number":58,"context_line":"memory has been copied. However there is a period of time where the port"},{"line_number":59,"context_line":"is bound to the destination host and the virtual machine is still running on"},{"line_number":60,"context_line":"the source host. During this period of time, the virtual machine won\u0027t be"},{"line_number":61,"context_line":"able to communicate, same as without this feature."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"When the virtual machine is unpaused in the destination host, the OVN"},{"line_number":64,"context_line":"backend is ready to immediately continue transmitting packets from the guess."}],"source_content_type":"text/x-rst","patch_set":5,"id":"c1ecf666_b70e89cf","line":61,"range":{"start_line":60,"start_character":17,"end_line":61,"end_character":50},"in_reply_to":"8cc00b69_0698ad88","updated":"2021-08-25 13:15:23.000000000","message":"thx for such detailed explanation on this :)","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"34abae619afcaea2e5d018255707808d81fea6b2","unresolved":true,"context_lines":[{"line_number":80,"context_line":"        ┌────────┐"},{"line_number":81,"context_line":"        │tap-xxx │           TAP interface port"},{"line_number":82,"context_line":"  ┌─────┴────────┴─────┐"},{"line_number":83,"context_line":"  │      pb-xxx        │     Port bridge"},{"line_number":84,"context_line":"  └─────┬────────┬─────┘"},{"line_number":85,"context_line":"        │pbp-xxx │           Port bridge patch port (port bridge side)"},{"line_number":86,"context_line":"        └────┬───┘"}],"source_content_type":"text/x-rst","patch_set":5,"id":"b0ba45f8_16befee5","line":83,"updated":"2021-08-25 13:15:23.000000000","message":"nitty nit: to make it all consistent regarding lenght of port_id which is used in names maybe it could be \"pbr-xxx\"?","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":false,"context_lines":[{"line_number":80,"context_line":"        ┌────────┐"},{"line_number":81,"context_line":"        │tap-xxx │           TAP interface port"},{"line_number":82,"context_line":"  ┌─────┴────────┴─────┐"},{"line_number":83,"context_line":"  │      pb-xxx        │     Port bridge"},{"line_number":84,"context_line":"  └─────┬────────┬─────┘"},{"line_number":85,"context_line":"        │pbp-xxx │           Port bridge patch port (port bridge side)"},{"line_number":86,"context_line":"        └────┬───┘"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a3c6665f_7b9367a8","line":83,"in_reply_to":"b0ba45f8_16befee5","updated":"2021-08-30 14:43:25.000000000","message":"Done","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":117,"context_line":"OVN backend only."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Nova - Neutron events"},{"line_number":121,"context_line":"---------------------"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Nova and Neutron have a mechanism to communicate the state of the VIFs [6]_."}],"source_content_type":"text/x-rst","patch_set":5,"id":"cb66789b_7cd131b4","line":120,"range":{"start_line":120,"start_character":0,"end_line":120,"end_character":21},"updated":"2021-08-24 12:21:05.000000000","message":"this is the most important part of the spec\n\nright now we had to disabel waiting for event when live migrating using ovn.\nif ovn cna correctly implemnt seting the network-vif-plugged event we can start waiting\nfor it again during live migration.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4b59d4659c65689d71295e57e6adecbdface9622","unresolved":true,"context_lines":[{"line_number":117,"context_line":"OVN backend only."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Nova - Neutron events"},{"line_number":121,"context_line":"---------------------"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Nova and Neutron have a mechanism to communicate the state of the VIFs [6]_."}],"source_content_type":"text/x-rst","patch_set":5,"id":"39c91732_430983e2","line":120,"range":{"start_line":120,"start_character":0,"end_line":120,"end_character":21},"in_reply_to":"12f296b1_26232806","updated":"2021-11-24 14:50:00.000000000","message":"for ml2/ovs it was fixed by neutron already.\n\nthe events were workign by desgin for ml2/ovs but there was a bug in neutron which rodoflo fixed.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":true,"context_lines":[{"line_number":117,"context_line":"OVN backend only."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Nova - Neutron events"},{"line_number":121,"context_line":"---------------------"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Nova and Neutron have a mechanism to communicate the state of the VIFs [6]_."}],"source_content_type":"text/x-rst","patch_set":5,"id":"12f296b1_26232806","line":120,"range":{"start_line":120,"start_character":0,"end_line":120,"end_character":21},"in_reply_to":"7d42a81b_966cfb35","updated":"2021-08-30 14:43:25.000000000","message":"Exactly, something similar is happening now with OVN","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"34abae619afcaea2e5d018255707808d81fea6b2","unresolved":true,"context_lines":[{"line_number":117,"context_line":"OVN backend only."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":""},{"line_number":120,"context_line":"Nova - Neutron events"},{"line_number":121,"context_line":"---------------------"},{"line_number":122,"context_line":""},{"line_number":123,"context_line":"Nova and Neutron have a mechanism to communicate the state of the VIFs [6]_."}],"source_content_type":"text/x-rst","patch_set":5,"id":"7d42a81b_966cfb35","line":120,"range":{"start_line":120,"start_character":0,"end_line":120,"end_character":21},"in_reply_to":"cb66789b_7cd131b4","updated":"2021-08-25 13:15:23.000000000","message":"not related to that spec but IIRC for ML2/OVS those events are also working \"by accident\" really as they are send when port on the src node is updated by neutron-ovs-agent and nova got it as event on destination node. At least it was like that some time ago, I\u0027m not sure if something changed there.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":124,"context_line":"This is a unidirectional API that allows Neutron to inform Nova when a VIF has"},{"line_number":125,"context_line":"been plugged or unplugged. Nova expects from Neutron a ``network-vif-plugged``"},{"line_number":126,"context_line":"event when the port has been bound or plugged. Depending on the backend, Nova"},{"line_number":127,"context_line":"will expect a ``network-vif-plugged`` when the port has been bound or when"},{"line_number":128,"context_line":"the port has been plugged [7]_. For example, in OVS with hybrid plug, Nova"},{"line_number":129,"context_line":"expects the event when the port has been plugged to the OVS. In OVN, Nova is"},{"line_number":130,"context_line":"expecting this event when the port has been bound during the live migration"},{"line_number":131,"context_line":"process [8]_."}],"source_content_type":"text/x-rst","patch_set":5,"id":"88f3383d_eb4a7271","line":128,"range":{"start_line":127,"start_character":37,"end_line":128,"end_character":26},"updated":"2021-08-24 12:21:05.000000000","message":"yes and know. we actully orginnaly intended to require it when it was plugged henc ethe name\nbut we were forced to relax that to accpet bind time event because of odl and later ovn since they were previaosly incapable of onnering the contract that linux bridge, ml2/ovs and the sriov nic agent followed.\n\n\nwe would stongly prefer to not have to deal with backend that send bind time event if we could.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":true,"context_lines":[{"line_number":124,"context_line":"This is a unidirectional API that allows Neutron to inform Nova when a VIF has"},{"line_number":125,"context_line":"been plugged or unplugged. Nova expects from Neutron a ``network-vif-plugged``"},{"line_number":126,"context_line":"event when the port has been bound or plugged. Depending on the backend, Nova"},{"line_number":127,"context_line":"will expect a ``network-vif-plugged`` when the port has been bound or when"},{"line_number":128,"context_line":"the port has been plugged [7]_. For example, in OVS with hybrid plug, Nova"},{"line_number":129,"context_line":"expects the event when the port has been plugged to the OVS. In OVN, Nova is"},{"line_number":130,"context_line":"expecting this event when the port has been bound during the live migration"},{"line_number":131,"context_line":"process [8]_."}],"source_content_type":"text/x-rst","patch_set":5,"id":"e1311902_34a3fa81","line":128,"range":{"start_line":127,"start_character":37,"end_line":128,"end_character":26},"in_reply_to":"88f3383d_eb4a7271","updated":"2021-08-30 14:43:25.000000000","message":"That will be no needed, this is handled by the mech driver.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":126,"context_line":"event when the port has been bound or plugged. Depending on the backend, Nova"},{"line_number":127,"context_line":"will expect a ``network-vif-plugged`` when the port has been bound or when"},{"line_number":128,"context_line":"the port has been plugged [7]_. For example, in OVS with hybrid plug, Nova"},{"line_number":129,"context_line":"expects the event when the port has been plugged to the OVS. In OVN, Nova is"},{"line_number":130,"context_line":"expecting this event when the port has been bound during the live migration"},{"line_number":131,"context_line":"process [8]_."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":"Once Nova creates the intermediate bridge [1]_ [2]_, Neutron can send the"},{"line_number":134,"context_line":"``network-vif-plugged`` event when the port is plugged and the network backend"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7ce5975f_4d3de37d","line":131,"range":{"start_line":129,"start_character":61,"end_line":131,"end_character":8},"updated":"2021-08-24 12:21:05.000000000","message":"yep this is to work around ml2/ovns current inablity to send it when its plugged.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":133,"context_line":"Once Nova creates the intermediate bridge [1]_ [2]_, Neutron can send the"},{"line_number":134,"context_line":"``network-vif-plugged`` event when the port is plugged and the network backend"},{"line_number":135,"context_line":"is configured."},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"This spec proposes to use the existing OVN event infrastructure to capture the"},{"line_number":138,"context_line":"patch port creation event, using ``LogicalSwitchPortCreateUpEvent``, and in"},{"line_number":139,"context_line":"the handler method push the event to Nova. Along with this change, Neutron will"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1ccdeb12_f7c88233","line":136,"updated":"2021-08-24 12:21:05.000000000","message":"+1 it would make our lives eiser if we did not have to spcial case ml2/ovn vs ml2/ovs","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"34abae619afcaea2e5d018255707808d81fea6b2","unresolved":true,"context_lines":[{"line_number":138,"context_line":"patch port creation event, using ``LogicalSwitchPortCreateUpEvent``, and in"},{"line_number":139,"context_line":"the handler method push the event to Nova. Along with this change, Neutron will"},{"line_number":140,"context_line":"inform Nova about the backend used in the port adding a field in"},{"line_number":141,"context_line":"``port.vif_details`` called ``ml2_plugin``. The value will be \"ovn\". This"},{"line_number":142,"context_line":"port update will be done in [9]_, in the mech driver port binding method."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"3d61a09f_f63d54e0","line":141,"range":{"start_line":141,"start_character":30,"end_line":141,"end_character":40},"updated":"2021-08-25 13:15:23.000000000","message":"what about 3rd party core plugins? Will they need to use \"ml2_plugin\" also? Maybe we should propose some more generic name, like \"backend\" maybe?","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":true,"context_lines":[{"line_number":138,"context_line":"patch port creation event, using ``LogicalSwitchPortCreateUpEvent``, and in"},{"line_number":139,"context_line":"the handler method push the event to Nova. Along with this change, Neutron will"},{"line_number":140,"context_line":"inform Nova about the backend used in the port adding a field in"},{"line_number":141,"context_line":"``port.vif_details`` called ``ml2_plugin``. The value will be \"ovn\". This"},{"line_number":142,"context_line":"port update will be done in [9]_, in the mech driver port binding method."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9fa37649_1b7f5890","line":141,"range":{"start_line":141,"start_character":30,"end_line":141,"end_character":40},"in_reply_to":"3d61a09f_f63d54e0","updated":"2021-08-30 14:43:25.000000000","message":"done","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":140,"context_line":"inform Nova about the backend used in the port adding a field in"},{"line_number":141,"context_line":"``port.vif_details`` called ``ml2_plugin``. The value will be \"ovn\". This"},{"line_number":142,"context_line":"port update will be done in [9]_, in the mech driver port binding method."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":""},{"line_number":145,"context_line":"Neutron configuration"},{"line_number":146,"context_line":"---------------------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"23718300_0a74cc5f","line":143,"updated":"2021-08-24 12:21:05.000000000","message":"nova can pass that info to os-vif an allow it to make backend specifc decisions in the future\nsuch as removeign the default value form the per-port bridge conffig option makign it a trinary\nwhere None means we decided automatically based on teh backend and true/false can be used to force enabel or disable per port bridges. eventually we would likely want to remvoe the option and just always make it automatic after a dprecation period","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":155,"context_line":""},{"line_number":156,"context_line":"If enabled, Neutron will send the ``network-vif-plugged`` when the port is"},{"line_number":157,"context_line":"plugged, not when the port binding is updated."},{"line_number":158,"context_line":""},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"QoS"},{"line_number":161,"context_line":"---"}],"source_content_type":"text/x-rst","patch_set":5,"id":"7d267cdc_5cf41c26","line":158,"updated":"2021-08-24 12:21:05.000000000","message":"one thing to keep in mind is it is ok to send extra events.\n\ne.g. it should not break nova if you send an event at both bind and plug time\n\nso you could jsut send it at both times and avoid the config option. with that said if we make per port bridge the default in yoga adn remove the os-vif config option in xena you would only have to send it at bind time until xena.\n\n\nthe config option also works for me but just incase you wanted to not have to set that.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"34abae619afcaea2e5d018255707808d81fea6b2","unresolved":true,"context_lines":[{"line_number":155,"context_line":""},{"line_number":156,"context_line":"If enabled, Neutron will send the ``network-vif-plugged`` when the port is"},{"line_number":157,"context_line":"plugged, not when the port binding is updated."},{"line_number":158,"context_line":""},{"line_number":159,"context_line":""},{"line_number":160,"context_line":"QoS"},{"line_number":161,"context_line":"---"}],"source_content_type":"text/x-rst","patch_set":5,"id":"e70a1c07_28f8fdcd","line":158,"in_reply_to":"7d267cdc_5cf41c26","updated":"2021-08-25 13:15:23.000000000","message":"\u003e one thing to keep in mind is it is ok to send extra events.\n\u003e \n\u003e e.g. it should not break nova if you send an event at both bind and plug time\n\u003e \n\u003e so you could jsut send it at both times and avoid the config option. with that said if we make per port bridge the default in yoga adn remove the os-vif config option in xena you would only have to send it at bind time until xena.\n\nI think it should be in the other way around as Xena is now and Yoga will be next release, no?\n\n\u003e \n\u003e \n\u003e the config option also works for me but just incase you wanted to not have to set that.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":167,"context_line":"in the same expression language used in the Logical_Flow table. The traffic"},{"line_number":168,"context_line":"shaping applied to the TAP device is the same when using the patch port"},{"line_number":169,"context_line":"reference because the traffic flow is the same in both ports."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"Performance"},{"line_number":173,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"41d213bf_2772535c","line":170,"updated":"2021-08-24 12:21:05.000000000","message":"this means no changes are required correct","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":true,"context_lines":[{"line_number":167,"context_line":"in the same expression language used in the Logical_Flow table. The traffic"},{"line_number":168,"context_line":"shaping applied to the TAP device is the same when using the patch port"},{"line_number":169,"context_line":"reference because the traffic flow is the same in both ports."},{"line_number":170,"context_line":""},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"Performance"},{"line_number":173,"context_line":"-----------"}],"source_content_type":"text/x-rst","patch_set":5,"id":"15a32967_b9ae1c25","line":170,"in_reply_to":"41d213bf_2772535c","updated":"2021-08-30 14:43:25.000000000","message":"Right, that works as is with the bridge per port architecture.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":185,"context_line":"--------"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Same as with other bridges (physical bridges, tunnel bridges, external"},{"line_number":188,"context_line":"bridges), each port plumber bridge will be connected to the integration bridge"},{"line_number":189,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":190,"context_line":"commented in the previous section."},{"line_number":191,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"7c403c14_65db30f6","line":188,"range":{"start_line":188,"start_character":20,"end_line":188,"end_character":27},"updated":"2021-08-24 12:21:05.000000000","message":"nit: delete","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":false,"context_lines":[{"line_number":185,"context_line":"--------"},{"line_number":186,"context_line":""},{"line_number":187,"context_line":"Same as with other bridges (physical bridges, tunnel bridges, external"},{"line_number":188,"context_line":"bridges), each port plumber bridge will be connected to the integration bridge"},{"line_number":189,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":190,"context_line":"commented in the previous section."},{"line_number":191,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"9c2fa497_6fab8e07","line":188,"range":{"start_line":188,"start_character":20,"end_line":188,"end_character":27},"in_reply_to":"7c403c14_65db30f6","updated":"2021-08-30 14:43:25.000000000","message":"Done","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":207,"context_line":""},{"line_number":208,"context_line":"This spec does not cover any scenario mixing TAP ports using both plug"},{"line_number":209,"context_line":"strategies on the same host (same as with OVS hybrid plugging strategy)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Testing"},{"line_number":213,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"c0c7d0c7_08ec63e5","line":210,"updated":"2021-08-24 12:21:05.000000000","message":"while its ineffecent i can proably add a second option to allow inplace migration to port bridges to os-vif\n\nthis will invovle checking for the existing of the port and bridges before pluging and potentially removing the old toplogy when creating the new toplogy.\n\nthis would nessacitate a small interuption to the network traffic of the guest mostlikely although if the port/bridge update where all done in a singel transaction its possibel that the update could be done atomicly with no datapath impact.\n\ni would be hesitant to enable this by default and i think the upgrade stragy should still be to do live migration,  but this is certainly something i can look into.\n\ni think the detail of that however are outside the scope of this spec and can be tracked as a rfe bug against os-vif directly to support inplace migraiton to per-port bridges.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":true,"context_lines":[{"line_number":207,"context_line":""},{"line_number":208,"context_line":"This spec does not cover any scenario mixing TAP ports using both plug"},{"line_number":209,"context_line":"strategies on the same host (same as with OVS hybrid plugging strategy)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Testing"},{"line_number":213,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"425fed4d_c5305280","line":210,"in_reply_to":"96c99423_c859cae4","updated":"2021-08-30 14:43:25.000000000","message":"+1\n\nI think this could be a nice add-on to the os-vif feature. However, for now, I\u0027ll keep this document as is not adding this possible feature.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"34abae619afcaea2e5d018255707808d81fea6b2","unresolved":true,"context_lines":[{"line_number":207,"context_line":""},{"line_number":208,"context_line":"This spec does not cover any scenario mixing TAP ports using both plug"},{"line_number":209,"context_line":"strategies on the same host (same as with OVS hybrid plugging strategy)."},{"line_number":210,"context_line":""},{"line_number":211,"context_line":""},{"line_number":212,"context_line":"Testing"},{"line_number":213,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d"}],"source_content_type":"text/x-rst","patch_set":5,"id":"96c99423_c859cae4","line":210,"in_reply_to":"c0c7d0c7_08ec63e5","updated":"2021-08-25 13:15:23.000000000","message":"+1","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11975,"name":"Slawek Kaplonski","email":"skaplons@redhat.com","username":"slaweq"},"change_message_id":"34abae619afcaea2e5d018255707808d81fea6b2","unresolved":true,"context_lines":[{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Live migration tempest tests are covered in the Nova CI. In order to test this"},{"line_number":219,"context_line":"feature, a set of tests from ``tempest.api.compute.admin.test_live_migration``"},{"line_number":220,"context_line":"should be executed on ``neutron-ovn-tempest-slow`` CI job."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":""},{"line_number":223,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":5,"id":"70a81246_40bfe964","line":220,"updated":"2021-08-25 13:15:23.000000000","message":"this job is to run tests marked as \"slow\" in tempest. But we can always rename it to run \"slow\" and some other tests too :)","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":true,"context_lines":[{"line_number":217,"context_line":""},{"line_number":218,"context_line":"Live migration tempest tests are covered in the Nova CI. In order to test this"},{"line_number":219,"context_line":"feature, a set of tests from ``tempest.api.compute.admin.test_live_migration``"},{"line_number":220,"context_line":"should be executed on ``neutron-ovn-tempest-slow`` CI job."},{"line_number":221,"context_line":""},{"line_number":222,"context_line":""},{"line_number":223,"context_line":"Documentation Impact"}],"source_content_type":"text/x-rst","patch_set":5,"id":"1a5e1ccf_070318ef","line":220,"in_reply_to":"70a81246_40bfe964","updated":"2021-08-30 14:43:25.000000000","message":"The point is that we are executing the migration test on this CI job, as it should be. We can document that, but I don\u0027t think we should change the job name.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":5948,"name":"Oleg Bondarev","email":"obondarev@mirantis.com","username":"obondarev"},"change_message_id":"eae7f8b75e300e8edaba097e2d766780acbb2d5a","unresolved":true,"context_lines":[{"line_number":246,"context_line":".. [2] https://review.opendev.org/c/openstack/nova/+/797428"},{"line_number":247,"context_line":".. [3] https://docs.openstack.org/nova/pike/admin/live-migration-usage.html"},{"line_number":248,"context_line":".. [4] https://github.com/openstack/os-vif/blob/e93736711920afe64a850f564dddefbd704975cd/vif_plug_ovs/ovs.py"},{"line_number":249,"context_line":".. [5] https://review.opendev.org/c/openstack/os-vif/+/798038"},{"line_number":250,"context_line":".. [6] https://wiki.openstack.org/wiki/Nova/ExternalEventAPI"},{"line_number":251,"context_line":".. [7] https://github.com/openstack/nova/blob/e7a7fd51d12d045ff134d55a4a1749c1feee0386/nova/network/model.py#L464-L481"},{"line_number":252,"context_line":".. [8] https://github.com/openstack/neutron/blob/13e96bf6bd740a09283d9e2849fc2b6adbbf29e3/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py#L796-L815"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a5b522ce_7ab55faf","line":249,"range":{"start_line":249,"start_character":7,"end_line":249,"end_character":61},"updated":"2021-08-24 11:26:22.000000000","message":"As Akihiro pointed, this seems a wrong link","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"25524111642cacb7ae6c6abee1365ac06813ab8d","unresolved":false,"context_lines":[{"line_number":246,"context_line":".. [2] https://review.opendev.org/c/openstack/nova/+/797428"},{"line_number":247,"context_line":".. [3] https://docs.openstack.org/nova/pike/admin/live-migration-usage.html"},{"line_number":248,"context_line":".. [4] https://github.com/openstack/os-vif/blob/e93736711920afe64a850f564dddefbd704975cd/vif_plug_ovs/ovs.py"},{"line_number":249,"context_line":".. [5] https://review.opendev.org/c/openstack/os-vif/+/798038"},{"line_number":250,"context_line":".. [6] https://wiki.openstack.org/wiki/Nova/ExternalEventAPI"},{"line_number":251,"context_line":".. [7] https://github.com/openstack/nova/blob/e7a7fd51d12d045ff134d55a4a1749c1feee0386/nova/network/model.py#L464-L481"},{"line_number":252,"context_line":".. [8] https://github.com/openstack/neutron/blob/13e96bf6bd740a09283d9e2849fc2b6adbbf29e3/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py#L796-L815"}],"source_content_type":"text/x-rst","patch_set":5,"id":"a1f7f8e6_3bc1d35c","line":249,"range":{"start_line":249,"start_character":7,"end_line":249,"end_character":61},"in_reply_to":"52ba1f96_2e659297","updated":"2021-08-30 14:43:25.000000000","message":"Done","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"cfe43b7a60f5717f8604687712e30a1c368e2a0a","unresolved":true,"context_lines":[{"line_number":246,"context_line":".. [2] https://review.opendev.org/c/openstack/nova/+/797428"},{"line_number":247,"context_line":".. [3] https://docs.openstack.org/nova/pike/admin/live-migration-usage.html"},{"line_number":248,"context_line":".. [4] https://github.com/openstack/os-vif/blob/e93736711920afe64a850f564dddefbd704975cd/vif_plug_ovs/ovs.py"},{"line_number":249,"context_line":".. [5] https://review.opendev.org/c/openstack/os-vif/+/798038"},{"line_number":250,"context_line":".. [6] https://wiki.openstack.org/wiki/Nova/ExternalEventAPI"},{"line_number":251,"context_line":".. [7] https://github.com/openstack/nova/blob/e7a7fd51d12d045ff134d55a4a1749c1feee0386/nova/network/model.py#L464-L481"},{"line_number":252,"context_line":".. [8] https://github.com/openstack/neutron/blob/13e96bf6bd740a09283d9e2849fc2b6adbbf29e3/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py#L796-L815"}],"source_content_type":"text/x-rst","patch_set":5,"id":"52ba1f96_2e659297","line":249,"range":{"start_line":249,"start_character":7,"end_line":249,"end_character":61},"in_reply_to":"a5b522ce_7ab55faf","updated":"2021-08-24 12:21:05.000000000","message":"https://review.opendev.org/c/openstack/os-vif/+/798055 adds the inital per port bridg support\n\nhttps://review.opendev.org/c/openstack/os-vif/+/805214 add vhost user support.","commit_id":"e017263f67e13b5191fbeb15f6c39225d0fe0961"},{"author":{"_account_id":29071,"name":"norman shen","email":"yshxxsjt715@gmail.com","username":"ushen"},"change_message_id":"0c49c7a4a9ab8f9150b210a1414aa0b948c8db85","unresolved":true,"context_lines":[{"line_number":18,"context_line":""},{"line_number":19,"context_line":"Since [1]_ and [2]_, Nova is capable of plugging the port and create the"},{"line_number":20,"context_line":"interface in the destination host during the pre-live migration. But the TAP"},{"line_number":21,"context_line":"device is created by libvirt when the VM is unpaused. This is when the port"},{"line_number":22,"context_line":"interface is assigned with an OpenFlow port ID."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"When the port is created, the network backend detects the new port attached"}],"source_content_type":"text/x-rst","patch_set":6,"id":"9c8995c3_a906ee69","line":21,"updated":"2024-03-14 07:54:11.000000000","message":"Is it true only for OVN case?","commit_id":"81f4ecb9d4b2218755908ddc855456297932a6f6"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"4b59d4659c65689d71295e57e6adecbdface9622","unresolved":true,"context_lines":[{"line_number":136,"context_line":""},{"line_number":137,"context_line":"This spec proposes to use the existing OVN event infrastructure to capture the"},{"line_number":138,"context_line":"patch port creation event, using ``LogicalSwitchPortCreateUpEvent``, and in"},{"line_number":139,"context_line":"the handler method push the event to Nova. Along with this change, Neutron will"},{"line_number":140,"context_line":"inform Nova about the backend used in the port adding a field in"},{"line_number":141,"context_line":"``port.vif_details`` called ``backend``. The value will be \"ovn\". This"},{"line_number":142,"context_line":"port update will be done in [9]_, in the mech driver port binding method."},{"line_number":143,"context_line":""},{"line_number":144,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"33ef377b_5f8bd43f","line":141,"range":{"start_line":139,"start_character":45,"end_line":141,"end_character":40},"updated":"2021-11-24 14:50:00.000000000","message":"why are we not using the previousl agged on feild bound_drivers to capture this.\n\nhttps://specs.openstack.org/openstack/neutron-specs/specs/train/port-binding-extended-information.html","commit_id":"81f4ecb9d4b2218755908ddc855456297932a6f6"}],"specs/xena/ovn-plumber-bridge-live-migration.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"59a744a41d3385315151ca85d1993a1971dd32ed","unresolved":true,"context_lines":[{"line_number":16,"context_line":"When the destination hypervisor is prepared, the source virtual machine"},{"line_number":17,"context_line":"is paused and immediately unpaused in the destination host."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"When the virtual machine is unpaused, the hypervisor driver plugs the"},{"line_number":20,"context_line":"virtual machine port (or ports) to the backend (OVN). This is"},{"line_number":21,"context_line":"when the network backend detects the new port attached and informs to"},{"line_number":22,"context_line":"the OVN Northbound and this event is received by Neutron. The network backend"},{"line_number":23,"context_line":"is commanded to configure the needed rules for this new port."}],"source_content_type":"text/x-rst","patch_set":1,"id":"19117a0d_ccd9a10e","line":20,"range":{"start_line":19,"start_character":0,"end_line":20,"end_character":54},"updated":"2021-07-02 13:28:31.000000000","message":"actully no\nwe plug the ports on the destination in prelive migration before we create the\nvm on the destination host.\n\njust before the vm is created in the paused state the tap device is created by libvirt\nwhich is then detacted by ovs and assign an openflow port id since the netdev name matchs the name of the port we created in the ovsdb during pre live migration.\n\n\nplugging is the act of creating the port in the contolplane of the network backend\n\ne.g. the ovs-vsctl add-port or backend equivalent\n\nit is not the act of creating the interface on the dataplane.\n\nplugging normally happens before interface creation.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9a90d38080d681e488c6dbb44b5c927c44fd8fd2","unresolved":true,"context_lines":[{"line_number":16,"context_line":"When the destination hypervisor is prepared, the source virtual machine"},{"line_number":17,"context_line":"is paused and immediately unpaused in the destination host."},{"line_number":18,"context_line":""},{"line_number":19,"context_line":"When the virtual machine is unpaused, the hypervisor driver plugs the"},{"line_number":20,"context_line":"virtual machine port (or ports) to the backend (OVN). This is"},{"line_number":21,"context_line":"when the network backend detects the new port attached and informs to"},{"line_number":22,"context_line":"the OVN Northbound and this event is received by Neutron. The network backend"},{"line_number":23,"context_line":"is commanded to configure the needed rules for this new port."}],"source_content_type":"text/x-rst","patch_set":1,"id":"e5680bd4_88fb72f6","line":20,"range":{"start_line":19,"start_character":0,"end_line":20,"end_character":54},"in_reply_to":"19117a0d_ccd9a10e","updated":"2021-07-06 11:05:55.000000000","message":"Right, Nova (calling os-vif with [1][2]) is capable of plugging the VM port and create the interface, before the TAP device is created. Is the interface ofport what we need to be a valid one.\n\n\n[1]https://review.opendev.org/c/openstack/nova/+/602432\n[2]https://review.opendev.org/c/openstack/nova/+/797428","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"59a744a41d3385315151ca85d1993a1971dd32ed","unresolved":true,"context_lines":[{"line_number":25,"context_line":"The problem with this sequence of actions is that when the virtual"},{"line_number":26,"context_line":"machine is unpaused, the network backend is not ready to continue any"},{"line_number":27,"context_line":"network communication until the OVN controller (in the compute node) has set"},{"line_number":28,"context_line":"all needed OpenFlow rules and chassis configuration."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"Proposed Change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"6c88d4a7_2b1c49ed","line":28,"updated":"2021-07-02 13:28:31.000000000","message":"yes. this is partly caused by the fact that ml2/ovn does not send the network-vif-plugged event when it has finished installing the openflow rules as was the original intent of that event.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9a90d38080d681e488c6dbb44b5c927c44fd8fd2","unresolved":true,"context_lines":[{"line_number":25,"context_line":"The problem with this sequence of actions is that when the virtual"},{"line_number":26,"context_line":"machine is unpaused, the network backend is not ready to continue any"},{"line_number":27,"context_line":"network communication until the OVN controller (in the compute node) has set"},{"line_number":28,"context_line":"all needed OpenFlow rules and chassis configuration."},{"line_number":29,"context_line":""},{"line_number":30,"context_line":""},{"line_number":31,"context_line":"Proposed Change"}],"source_content_type":"text/x-rst","patch_set":1,"id":"117ae3c6_6619e9cf","line":28,"in_reply_to":"6c88d4a7_2b1c49ed","updated":"2021-07-06 11:05:55.000000000","message":"None of the Neutron backend does it (apart from OVS with hybrid pluggin since [1][2]). Any Neutron backend (OVS, OVN) can\u0027t configure anything, if the port interface ofport is invalid.\n\nThat was a consensual decision between Nova and Neutron to send the events when (OVS) the port was provisioned or (OVN) when the port binding had \"migrating_to\" key.\n\n[1]https://review.opendev.org/c/openstack/neutron/+/790702\n[2]https://review.opendev.org/c/openstack/nova/+/602432","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a0721a8ee0eb76c8dcf1f0829443047c42d01f1","unresolved":true,"context_lines":[{"line_number":65,"context_line":"        │pbi-xxx │           tap interface"},{"line_number":66,"context_line":"  ┌─────┴────────┴─────┐"},{"line_number":67,"context_line":"  │                    │"},{"line_number":68,"context_line":"  │      pb-xxx        │     plumber bridge"},{"line_number":69,"context_line":"  │                    │"},{"line_number":70,"context_line":"  └─────┬────────┬─────┘"},{"line_number":71,"context_line":"        │pbp-xxx │           patch port (plumber bridge side)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7e742e1a_3d17e50e","line":68,"range":{"start_line":68,"start_character":29,"end_line":68,"end_character":36},"updated":"2021-07-02 12:58:32.000000000","message":"port","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9a90d38080d681e488c6dbb44b5c927c44fd8fd2","unresolved":true,"context_lines":[{"line_number":65,"context_line":"        │pbi-xxx │           tap interface"},{"line_number":66,"context_line":"  ┌─────┴────────┴─────┐"},{"line_number":67,"context_line":"  │                    │"},{"line_number":68,"context_line":"  │      pb-xxx        │     plumber bridge"},{"line_number":69,"context_line":"  │                    │"},{"line_number":70,"context_line":"  └─────┬────────┬─────┘"},{"line_number":71,"context_line":"        │pbp-xxx │           patch port (plumber bridge side)"}],"source_content_type":"text/x-rst","patch_set":1,"id":"dc692fa0_f669d24b","line":68,"range":{"start_line":68,"start_character":29,"end_line":68,"end_character":36},"in_reply_to":"7e742e1a_3d17e50e","updated":"2021-07-06 11:05:55.000000000","message":"I don\u0027t know why I though that was \"plumber\".","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a0721a8ee0eb76c8dcf1f0829443047c42d01f1","unresolved":true,"context_lines":[{"line_number":68,"context_line":"  │      pb-xxx        │     plumber bridge"},{"line_number":69,"context_line":"  │                    │"},{"line_number":70,"context_line":"  └─────┬────────┬─────┘"},{"line_number":71,"context_line":"        │pbp-xxx │           patch port (plumber bridge side)"},{"line_number":72,"context_line":"        └────┬───┘"},{"line_number":73,"context_line":"             │"},{"line_number":74,"context_line":"        ┌────┴───┐"}],"source_content_type":"text/x-rst","patch_set":1,"id":"5e655b1d_8040b87e","line":71,"range":{"start_line":71,"start_character":41,"end_line":71,"end_character":48},"updated":"2021-07-02 12:58:32.000000000","message":"port","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a0721a8ee0eb76c8dcf1f0829443047c42d01f1","unresolved":true,"context_lines":[{"line_number":72,"context_line":"        └────┬───┘"},{"line_number":73,"context_line":"             │"},{"line_number":74,"context_line":"        ┌────┴───┐"},{"line_number":75,"context_line":"        │tap-xxx │           patch port (integration bridge side)"},{"line_number":76,"context_line":"  ┌─────┴────────┴─────┐"},{"line_number":77,"context_line":"  │                    │"},{"line_number":78,"context_line":"  │                    │"}],"source_content_type":"text/x-rst","patch_set":1,"id":"064654ea_ab54f09e","line":75,"range":{"start_line":75,"start_character":9,"end_line":75,"end_character":17},"updated":"2021-07-02 12:58:32.000000000","message":"i cannot do this without a change to nova at which point i cannot backport the os-vif changes\nas the nova change woudl require a newer min os-vif lib to use this as i would have ot allow nova to pass 2 seperate names.\n\nlooking at the nova and neutron code currently we do not support specifyting the name of the port form nutron to nove. we can pass the bridge name but the name of the port on the integration bridge is at novas discression.\n\nby convention we have agreed not to change them but ovn and the ovs l2 agent shoudl soley be using the extrenal_ids info to determin what to do with the port and not then name.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"59a744a41d3385315151ca85d1993a1971dd32ed","unresolved":true,"context_lines":[{"line_number":92,"context_line":"This is a unidirectional API the allows Neutron to inform Nova when a VIF has"},{"line_number":93,"context_line":"been plugged or unplugged. Nova expects from Neutron a ``network-vif-plugged``"},{"line_number":94,"context_line":"event created from the destination host. At this point, Nova considers the"},{"line_number":95,"context_line":"network backend is properly configured and proceeds to unpause the virtual"},{"line_number":96,"context_line":"machine in the destination host."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Now the Neutron server, when the OVN backend is used, sends this event during"},{"line_number":99,"context_line":"the port update postcommit method [2]_. As described in this code section,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"502b73ea_377700f1","line":96,"range":{"start_line":95,"start_character":43,"end_line":96,"end_character":32},"updated":"2021-07-02 13:28:31.000000000","message":"this is not correct in 2 ways.\n\nbecause ml2/ovn does not seend pulg time event only bind time events today we do not waith in the case of ovn.\n\nbecause we dont know what ml2 dirver bound the vif we are froce to infer this based on hybrid plug\nhttps://github.com/openstack/nova/blob/master/nova/network/model.py#L464-L481\nhttps://github.com/openstack/nova/blob/d03a600461db7d0fe0d6a9f522c30b890c691353/nova/network/model.py#L543-L562\n\n the second issuse is that we plug the interface in pre-live migration not during the migration.\n\nhttps://github.com/openstack/nova/blob/d03a600461db7d0fe0d6a9f522c30b890c691353/nova/compute/manager.py#L8321-L8341\nhttps://github.com/openstack/nova/blob/d03a600461db7d0fe0d6a9f522c30b890c691353/nova/compute/manager.py#L8244-L8252\n\nso for backends that send plugtime event we wait to start the migration until we get the network-vif-plugged event.\n\nhttps://github.com/openstack/nova/blob/d03a600461db7d0fe0d6a9f522c30b890c691353/nova/compute/manager.py#L8406-L8408\nhttps://github.com/openstack/nova/blob/d03a600461db7d0fe0d6a9f522c30b890c691353/nova/compute/manager.py#L8448-L8451\n\nfor ovn since it will never notify use when the dest is ready we just start the migration.\n\nideally ml2/ovn will be modified to notify us when the destination is plugged and then we could wait.\n\nin train https://specs.openstack.org/openstack/neutron-specs/specs/train/port-binding-extended-information.html was added but we drop the part about when each driver will send events.\n\nso unfrotently we still do not know if we the backend will send plugtime or bidning time network_vif_plugged events.\n\nwe can and should start using that extenion in nova to allow things like adressless prot for l2 networks or differenciate between ml2/ovs and ml2 ovn  to enable vir isolation but we have not done that yet.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9a90d38080d681e488c6dbb44b5c927c44fd8fd2","unresolved":true,"context_lines":[{"line_number":92,"context_line":"This is a unidirectional API the allows Neutron to inform Nova when a VIF has"},{"line_number":93,"context_line":"been plugged or unplugged. Nova expects from Neutron a ``network-vif-plugged``"},{"line_number":94,"context_line":"event created from the destination host. At this point, Nova considers the"},{"line_number":95,"context_line":"network backend is properly configured and proceeds to unpause the virtual"},{"line_number":96,"context_line":"machine in the destination host."},{"line_number":97,"context_line":""},{"line_number":98,"context_line":"Now the Neutron server, when the OVN backend is used, sends this event during"},{"line_number":99,"context_line":"the port update postcommit method [2]_. As described in this code section,"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2a90d519_b8a0a968","line":96,"range":{"start_line":95,"start_character":43,"end_line":96,"end_character":32},"in_reply_to":"502b73ea_377700f1","updated":"2021-07-06 11:05:55.000000000","message":"I know the interface is plugged during the live-migration. The main problem we have, you know this better than me, is that the interface ofport is invalid. Thus the backend cannot configure the needed OF rules.\n\nWe send the vif-plugged-event same as in OVS, \"when we can\". That was because we didn\u0027t have [1] and the port was created and plugged when the VM was unpaused. It is very difficult to tell Nova that the backend is ready when you wait for a \"vif-plugged-event\" to create the port. The events process was inverted.\n\nThis is why [2] was implemented. OVN was unable to send a vif-plugged-event because actually there was not port creation. Then we implemented this workaround to send you the expected event.\n\nSince [1] we can resolve the issue of detecting the port. The issue we want to solve with this spec (and this is your idea that I support) is to both plug a port with an interface with a valid ofport to allow OVN to create the needed OF rules.\n\n[1]https://review.opendev.org/c/openstack/nova/+/602432\n[2]https://github.com/openstack/neutron/blob/97618b08769636ec07b994b26af5d73bae4e5a6c/neutron/plugins/ml2/drivers/ovn/mech_driver/mech_driver.py#L796-L815","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"59a744a41d3385315151ca85d1993a1971dd32ed","unresolved":true,"context_lines":[{"line_number":100,"context_line":"this is a fake way to generate the event needed by Nova. However, that doesn’t"},{"line_number":101,"context_line":"guarantee the backend is ready; this is just a workaround when"},{"line_number":102,"context_line":"``live_migration_wait_for_vif_plug`` is True."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"This spec proposes to use the existing OVN event infrastructure to capture the"},{"line_number":105,"context_line":"patch port creation event, using ``LogicalSwitchPortCreateUpEvent``, and in"},{"line_number":106,"context_line":"the handler method push the event to Nova. The workaround currently"}],"source_content_type":"text/x-rst","patch_set":1,"id":"468d7d7d_e68d1be1","line":103,"updated":"2021-07-02 13:28:31.000000000","message":"it should not be required for that case i think since currently we skip waiting in prelive migrate","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9a90d38080d681e488c6dbb44b5c927c44fd8fd2","unresolved":true,"context_lines":[{"line_number":100,"context_line":"this is a fake way to generate the event needed by Nova. However, that doesn’t"},{"line_number":101,"context_line":"guarantee the backend is ready; this is just a workaround when"},{"line_number":102,"context_line":"``live_migration_wait_for_vif_plug`` is True."},{"line_number":103,"context_line":""},{"line_number":104,"context_line":"This spec proposes to use the existing OVN event infrastructure to capture the"},{"line_number":105,"context_line":"patch port creation event, using ``LogicalSwitchPortCreateUpEvent``, and in"},{"line_number":106,"context_line":"the handler method push the event to Nova. The workaround currently"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a483d705_fd37f44e","line":103,"in_reply_to":"468d7d7d_e68d1be1","updated":"2021-07-06 11:05:55.000000000","message":"Then if we skip this waiting time, what is the purpose of this spec? The goal is to have a sequence of sync events and actions. If we skip this time, this spec has no sense.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"59a744a41d3385315151ca85d1993a1971dd32ed","unresolved":true,"context_lines":[{"line_number":104,"context_line":"This spec proposes to use the existing OVN event infrastructure to capture the"},{"line_number":105,"context_line":"patch port creation event, using ``LogicalSwitchPortCreateUpEvent``, and in"},{"line_number":106,"context_line":"the handler method push the event to Nova. The workaround currently"},{"line_number":107,"context_line":"implemented will be removed."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"QoS"}],"source_content_type":"text/x-rst","patch_set":1,"id":"650bb709_ed89ade1","line":107,"updated":"2021-07-02 13:28:31.000000000","message":"but yes this would be much better howwever we need somethign in the prot or vif details to know that you send these events or we will have to add a config option in nova to enable waiting with ovn.\n\ni guess a workaround config option to disable waiting with ovn would be better since we woudl want to wait by default and we woudl only disable it for upgrade reasons.\n\n\nplease do implement this in neutron though as i woudl love to remove the hacks we have on the nova side to workaorund this.\nunfortuenetly we may still need to keep this for odl altough they were already have ment to fix this.\ni jsut dont know if they ever did.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9a90d38080d681e488c6dbb44b5c927c44fd8fd2","unresolved":true,"context_lines":[{"line_number":104,"context_line":"This spec proposes to use the existing OVN event infrastructure to capture the"},{"line_number":105,"context_line":"patch port creation event, using ``LogicalSwitchPortCreateUpEvent``, and in"},{"line_number":106,"context_line":"the handler method push the event to Nova. The workaround currently"},{"line_number":107,"context_line":"implemented will be removed."},{"line_number":108,"context_line":""},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"QoS"}],"source_content_type":"text/x-rst","patch_set":1,"id":"513f66b7_bd449ae7","line":107,"in_reply_to":"650bb709_ed89ade1","updated":"2021-07-06 11:05:55.000000000","message":"I\u0027ll add a flag in the port vif_details, added during the port binding, to identify the backend used.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a0721a8ee0eb76c8dcf1f0829443047c42d01f1","unresolved":true,"context_lines":[{"line_number":116,"context_line":"integration bridge is the patch port. QoS cannot be applied on an internal"},{"line_number":117,"context_line":"port."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"(***to be continued: how the extension reads the TAP port ID and applies the QoS on it***)"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"Performance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"20d31059_9695eadc","line":119,"updated":"2021-07-02 12:58:32.000000000","message":"as i commented on the os-vif patch \nhttps://review.opendev.org/c/openstack/os-vif/+/798055/10#message-25879769ae40bce01578d1c53ce97877c24ccae8\n\ni could also add a new port-ref in the external_ids\n    external_ids \u003d {\n                \u0027iface-id\u0027: iface_id, \u0027iface-status\u0027: \u0027active\u0027,\n                \u0027attached-mac\u0027: mac, \u0027vm-uuid\u0027: instance_id,\n                \u0027port-ref\u0027: vif.vif_name\n            }\n\nwhich would hold the name the tap port.\n\ni cannot use the tap**** name on the br-int and teh qos extension and ovn shoudl not make any dependency on the name of the port it should only be using the external_ids as the name of the port is not part of the contact between nova and neutron.\n\nthe default devname is hardcorded in nova \nhttps://github.com/openstack/nova/blob/master/nova/network/neutron.py#L3055-L3056\nwhich is tap\u003cuuid\u003e truncated to 14 letters\n\n\nwhen we os-\u003dvif obejcts we just retrive the dev name value form our internel nova vif object\nhttps://github.com/openstack/nova/blob/d03a600461db7d0fe0d6a9f522c30b890c691353/nova/network/os_vif_util.py#L350-L358\n\n\nwhen doing hybrid plug for upgrade reason we maintain the old (qvo qvb) names for the veth pair so we do not leak interfaces https://github.com/openstack/os-vif/blob/e93736711920afe64a850f564dddefbd704975cd/vif_plug_ovs/ovs.py#L105-L107 but there is nothing in the api contract between nova and neutorn that would prevent nov or so-vif from changing those since they must not be relied upon by the l2 agent.\n\nit may only depend on the external id and the same is true for ovn.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":16688,"name":"Rodolfo Alonso","email":"ralonsoh@redhat.com","username":"rodolfo-alonso-hernandez"},"change_message_id":"9a90d38080d681e488c6dbb44b5c927c44fd8fd2","unresolved":false,"context_lines":[{"line_number":116,"context_line":"integration bridge is the patch port. QoS cannot be applied on an internal"},{"line_number":117,"context_line":"port."},{"line_number":118,"context_line":""},{"line_number":119,"context_line":"(***to be continued: how the extension reads the TAP port ID and applies the QoS on it***)"},{"line_number":120,"context_line":""},{"line_number":121,"context_line":""},{"line_number":122,"context_line":"Performance"}],"source_content_type":"text/x-rst","patch_set":1,"id":"a557a820_b2239fbb","line":119,"in_reply_to":"20d31059_9695eadc","updated":"2021-07-06 11:05:55.000000000","message":"Done","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"8a0721a8ee0eb76c8dcf1f0829443047c42d01f1","unresolved":true,"context_lines":[{"line_number":131,"context_line":"effect on packet processing performance."},{"line_number":132,"context_line":""},{"line_number":133,"context_line":""},{"line_number":134,"context_line":"OVN DPDK"},{"line_number":135,"context_line":"--------"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"Same as with other bridges (physical bridges, tunnel bridges, external"},{"line_number":138,"context_line":"bridges), each port plumber bridge will be connected to the integration bridge"},{"line_number":139,"context_line":"with a patch port. That keeps one single datapath (“netdev” in DPDK case), as"},{"line_number":140,"context_line":"commented in the previous section."},{"line_number":141,"context_line":""},{"line_number":142,"context_line":""},{"line_number":143,"context_line":"References"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4051ae15_789584c6","line":140,"range":{"start_line":134,"start_character":0,"end_line":140,"end_character":34},"updated":"2021-07-02 12:58:32.000000000","message":"i have not currently implemeted this for vhost-user but i can add that.\n\nwe have never had this reproted for ovs-dpdk but arguably with ovs-dpdk it\nnot only can happen for migration but also for boot since the ofport-id will be -1 until\nqemu adn ovs connect over the unix socket.","commit_id":"a3d956fb98423fcb2c1aa35346dd23d8b8158d45"}]}