© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
ovn is broken in a different way but with a similar effect.
there is yet another vector for a race between libvirt and ovn in the ovn case.
ovn will not install openflow rules until libvirt creates the tap on the destinatnion host.
as a result there is an interval of time where the vm can be runnign on the dest but ovn has not installed the flows if the
there was a bug in the nova fix which is resolved by
https:/
https:/
basically the nova fix was turned off due to an issue in the code related to who python properties work.
that is corrected by those last too patch and that is being squshed into the backport of the nova patch.
now that we know ovn has different requirement that we must fullfile to mitigate the race condition in the ovn case i am prototyping https:/
as a solution taht will actully also fix the ovn varent of this.
funementailly if you nighevly live migrate between two hsts with ovn you will always have a race condition between libvirt and ovn unless we can remove the depency on the of-portid that only gets assigned wehn the device is created on the datapath on the host.
to work around this we are oging to create per port ovs bridges and connnoect those to the br-int
this is similar to how hybrid plug works with ml2/ovs and iptabel or to how we implement trunk port in ml2/ovs. unlike hybrid plugs we will not be using linux bridges and we will not have the performace impact that intoduces
the trunk bridge concept is not new in ml2/ovs so the port bridge design is more or less well tested since we are using the same techniuq just for a different usecase.
ironicly the fix for ovn will also work for ml2/ovs and would have avoid some of the change we already made for ml2/ovs to adress this in the first place but it was intially dismissed as it results in a more complex bridge toplogy which at the time we did nto want to intoduce since ml2/ovs did not need it.