<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Thanks for all your hard work on this.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I'm wondering is there any doc proposed for devstack to tell people who are not interested in OVN to keep the current devstack behaviour? I have a feeling that using OVN as default Neutron driver would break the CI jobs for some projects like Octavia, Trove, etc. which rely on ovs port for the set up.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="color:rgb(102,102,102);font-family:monospace,monospace"><br></span></div><div><span style="color:rgb(102,102,102);font-family:monospace,monospace">---</span><br></div><div><font color="#666666" face="monospace, monospace">Lingxian Kong</font></div><div><font color="#666666" face="monospace, monospace">Senior Cloud Engineer (Catalyst Cloud)</font></div><div><font color="#666666" face="monospace, monospace">Trove PTL (OpenStack)</font></div><div><font color="#666666" face="monospace, monospace">OpenStack Cloud Provider Co-Lead (Kubernetes)</font><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 3, 2021 at 2:03 PM Goutham Pacha Ravi <<a href="mailto:gouthampravi@gmail.com">gouthampravi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, Mar 1, 2021 at 10:29 AM Sean Mooney <<a href="mailto:smooney@redhat.com" target="_blank">smooney@redhat.com</a>> wrote:<br>
><br>
> On Mon, 2021-03-01 at 16:07 +0000, Lucas Alvares Gomes wrote:<br>
> > Hi all,<br>
> ><br>
> > As part of the Victoria PTG [0] the Neutron community agreed upon<br>
> > switching the default backend in Devstack to OVN. A lot of work has<br>
> > been done since, from porting the OVN devstack module to the DevStack<br>
> > tree, refactoring the DevStack module to install OVN from distro<br>
> > packages, implementing features to close the parity gap with ML2/OVS,<br>
> > fixing issues with tests and distros, etc...<br>
> ><br>
> > We are now very close to being able to make the switch and we've<br>
> > thought about sending this email to the broader community to raise<br>
> > awareness about this change as well as bring more attention to the<br>
> > patches that are current on review.<br>
> ><br>
> > Note that moving DevStack to ML2/OVN does not mean that ML2/OVS is<br>
> > discontinued and/or not supported anymore. The ML2/OVS driver is still<br>
> > going to be developed and maintained by the upstream Neutron<br>
> > community.<br>
> can we ensure that this does not happen until the xena release.<br>
> in generall i think its ok to change the default but not this late in the cycle.<br>
> i would also like to ensure we keep at least one non ovn based multi node job in<br>
> nova until <a href="https://review.opendev.org/c/openstack/nova/+/602432" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/nova/+/602432</a> is merged and possible after.<br>
> right now the event/neutorn interaction is not the same during move operations.<br>
> ><br>
> > Below is a e per project explanation with relevant links and issues of<br>
> > where we stand with this work right now:<br>
> ><br>
> > * Keystone:<br>
> ><br>
> > Everything should be good for Keystone, the gate is happy with the<br>
> > changes. Here is the test patch:<br>
> > <a href="https://review.opendev.org/c/openstack/keystone/+/777963" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/keystone/+/777963</a><br>
> ><br>
> > * Glance:<br>
> ><br>
> > Everything should be good for Glace, the gate is happy with the<br>
> > changes. Here is the test patch:<br>
> > <a href="https://review.opendev.org/c/openstack/glance/+/748390" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/glance/+/748390</a><br>
> ><br>
> > * Swift:<br>
> ><br>
> > Everything should be good for Swift, the gate is happy with the<br>
> > changes. Here is the test patch:<br>
> > <a href="https://review.opendev.org/c/openstack/swift/+/748403" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/swift/+/748403</a><br>
> ><br>
> > * Ironic:<br>
> ><br>
> > Since chainloading iPXE by the OVN built-in DHCP server is work in<br>
> > progress, we've changed most of the Ironic jobs to explicitly enable<br>
> > ML2/OVS and everything is merged, so we should be good for Ironic too.<br>
> > Here is the test patch:<br>
> > <a href="https://review.opendev.org/c/openstack/ironic/+/748405" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/ironic/+/748405</a><br>
> ><br>
> > * Cinder:<br>
> ><br>
> > Cinder is almost complete. There's one test failure in the<br>
> > "tempest-slow-py3" job run on the<br>
> > "test_port_security_macspoofing_port" test.<br>
> ><br>
> > This failure is due to a bug in core OVN [1]. This bug has already<br>
> > been fixed upstream [2] and the fix has been backported down to the<br>
> > branch-20.03 [3] of the OVN project. However, since we install OVN<br>
> > from packages we are currently waiting for this fix to be included in<br>
> > the packages for Ubuntu Focal (it's based on OVN 20.03). I already<br>
> > contacted the package maintainer which has been very supportive of<br>
> > this work and will work on the package update, but he maintain a<br>
> > handful of backports in that package which is not yet included in OVN<br>
> > 20.03 upstream and he's now working with the core OVN community [4] to<br>
> > include it first in the branch and then create a new package for it.<br>
> > Hopefully this will happen soon.<br>
> ><br>
> > But for now we have a few options moving on with this issue:<br>
> ><br>
> > 1- Wait for the new package version<br>
> > 2- Mark the test as unstable until we get the new package version<br>
> > 3- Compile OVN from source instead of installing it from packages<br>
> > (OVN_BUILD_FROM_SOURCE=True in local.conf)<br>
> i dont think we should default to ovn untill a souce build is not required.<br>
> compiling form souce while not supper expensice still adds time to the job<br>
> execution and im not sure we should be paying that cost on every devstack job run.<br>
><br>
> we could maybe compile it once and bake the package into the image or host it on a mirror<br>
> but i think we should avoid this option if we have alternitives.<br>
> ><br>
> > What do you think about it ?<br>
> ><br>
> > Here is the test patch for Cinder:<br>
> > <a href="https://review.opendev.org/c/openstack/cinder/+/748227" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/cinder/+/748227</a><br>
> ><br>
> > * Nova:<br>
> ><br>
> > There are a few patches waiting for review for Nova, which are:<br>
> ><br>
> > 1- Adapting the live migration scripts to work with ML2/OVN: Basically<br>
> > the scripts were trying to stop the Neutron agent (q-agt) process<br>
> > which is not part of an ML2/OVN deployment. The patch changes the code<br>
> > to check if that system unit exists before trying to stop it.<br>
> ><br>
> > Patch: <a href="https://review.opendev.org/c/openstack/nova/+/776419" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/nova/+/776419</a><br>
> ><br>
> > 2- Explicitly set grenade job to ML2/OVS: This is a temporary change<br>
> > which can be removed one release cycle after we switch DevStack to<br>
> > ML2/OVN. Grenade will test updating from the release version to the<br>
> > master branch but, since the default of the released version is not<br>
> > ML2/OVN, upgrading from ML2/OVS to ML2/OVN as part of the grenade job<br>
> > is not supported.<br>
> ><br>
> > Patch: <a href="https://review.opendev.org/c/openstack/nova/+/776934" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/nova/+/776934</a><br>
> ><br>
> > 3- Explicitly set nova-next job to ML2/OVS: This job uses the QoS<br>
> > minimum bandwidth feature which is not yet supported by ML2/OVN [5][6]<br>
> > therefore we are temporarily enabling ML2/OVS for this job until that<br>
> > feature lands in core OVN.<br>
> ><br>
> > Patch: <a href="https://review.opendev.org/c/openstack/nova/+/776944" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/nova/+/776944</a><br>
> ><br>
> > I also spoke briefly with Sean Mooney (irc: sean-k-mooney) about these<br>
> > changes and he suggested keeping all the Nova jobs on ML2/OVS for now<br>
> > because he feels like a change in the default network driver a few<br>
> > weeks prior to the upstream code freeze can be concerning. We do not<br>
> > know yet precisely when we are changing the default due to the current<br>
> > patches we need to get merged but, if this is a shared feeling among<br>
> > the Nova community I can work on enabling ML2/OVS on all jobs in Nova<br>
> > until we get a new release in OpenStack.<br>
> yep this is still my view.<br>
> i would suggest we do the work required in the repos but not merge it until the xena release<br>
> is open. thats technically at RC1 so march 25th<br>
> i think we can safely do the swich after that but i would not change the defualt in any project<br>
> before then.<br>
> ><br>
> > Here's the test patch for Nova:<br>
> > <a href="https://review.opendev.org/c/openstack/nova/+/776945" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/nova/+/776945</a><br>
> ><br>
> > * DevStack:<br>
> ><br>
> > And this is the final patch that will make this all happen:<br>
> > <a href="https://review.opendev.org/c/openstack/devstack/+/735097" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/devstack/+/735097</a><br>
> ><br>
> > It changes the default in DevStack from ML2/OVS to ML2/OVN. It's been<br>
> > a long and bumpy road to get to this point and I would like to say<br>
> > thanks to everyone involved so far and everyone that read the whole<br>
> > email, please let me know your thoughts.<br>
> thanks for working on this.<br>
> ><br>
> > [0] <a href="https://etherpad.opendev.org/p/neutron-victoria-ptg" rel="noreferrer" target="_blank">https://etherpad.opendev.org/p/neutron-victoria-ptg</a><br>
> > [1] <a href="https://bugs.launchpad.net/tempest/+bug/1728886" rel="noreferrer" target="_blank">https://bugs.launchpad.net/tempest/+bug/1728886</a><br>
> > [2] <a href="https://patchwork.ozlabs.org/project/openvswitch/patch/20200319122641.473776-1-numans@ovn.org/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.org/project/openvswitch/patch/20200319122641.473776-1-numans@ovn.org/</a><br>
> > [3] <a href="https://github.com/ovn-org/ovn/commit/0c26bc03064f2c21d208f0f860b48d8ab39380cb" rel="noreferrer" target="_blank">https://github.com/ovn-org/ovn/commit/0c26bc03064f2c21d208f0f860b48d8ab39380cb</a><br>
> > [4] <a href="https://mail.openvswitch.org/pipermail/ovs-discuss/2021-February/050961.html" rel="noreferrer" target="_blank">https://mail.openvswitch.org/pipermail/ovs-discuss/2021-February/050961.html</a><br>
> > [5] <a href="https://github.com/openstack/nova/blob/ded25f33c734ebff963f06984707a99fe76a9ee1/gate/post_test_hook.sh#L129-L143" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/ded25f33c734ebff963f06984707a99fe76a9ee1/gate/post_test_hook.sh#L129-L143</a><br>
> > [6] <a href="https://docs.openstack.org/neutron/latest/ovn/gaps.html" rel="noreferrer" target="_blank">https://docs.openstack.org/neutron/latest/ovn/gaps.html</a><br>
> ><br>
> > Cheers,<br>
> > Lucas<br>
<br>
++ Thank you indeed for working diligently on this important change.<br>
<br>
Please do note that devstack, and the base job that you're modifying<br>
is used by many other projects besides the ones that you have<br>
enumerated in the subject line.<br>
I suggest using [all] as a better subject line indicator to get the<br>
attention of folks like me who have filters based on the subject line.<br>
Also, the network substrate is important for the project I help<br>
maintain: Manila, which provides shared file systems over a network -<br>
so I followed your lead and submitted a dependent patch. I hope to<br>
reach out to you in case we see some breakages:<br>
<a href="https://review.opendev.org/c/openstack/manila-tempest-plugin/+/778346" rel="noreferrer" target="_blank">https://review.opendev.org/c/openstack/manila-tempest-plugin/+/778346</a><br>
<br>
> ><br>
><br>
><br>
><br>
<br>
</blockquote></div>