Open Stack

Hi all,

Just giving my fellows an update from the event where we gathered our  
upgrades subteam to plan for Newton and do some coding.

==

We had folks from multiple companies participating in the event (Red Hat,  
SuSE, Intel, IBM). We also had some folks joining us online. Thanks  
everyone who gave us a hand at these days!

For the most part, we were working on the plan to adopt versioned objects  
for neutron db codebase. Just in case someone is not aware about the end  
goal for the effort: we want to eventually get to the point where you can  
upgrade your neutron-server processes between major releases without  
shutting all of them down to run database migration scripts. [There are  
other applications for objects, but that’s currently out of immediate scope  
for the N effort.]

Long story short, the current plan of the team for the near future is:

- N: provide objects for all major neutron resources;
- N: get most if not all the db code in neutron repo switched to using  
objects;
- N: start using objects to handle database live data migration (aka  
‘contract’ scripts);
- start of O: forbid contract alembic scripts;
- O and beyond: introduce gating for HA neutron-servers; complete objects  
adoption; look into utilizing objects for plugin API; API version pinning;  
...

If all goes well, this plan should allow ops to upgrade Newton  
neutron-server to O without API endpoint downtime.

==

We also discussed current gating for upgrades. The plan for that would be  
getting the current l3 legacy job voting next weeks; adding dvr flavor into  
check queue (non-voting); get voting for the latter (probably while  
removing the former from check gate).

There are still some things to improve in multinode grenade that we have.

One thing is that we should look into running dvr tests for dvr flavour of  
the job. Though there are some dvr tests in tempest, they are not tagged as  
smoke, and hence are not executed in the job. Also, as per Assaf, those dvr  
tests go away from tempest middle term, leaving just tests inside neutron  
tree. So we should come up with some way to run dvr tests that are  
maintained inside neutron tree. One way is utilizing a tempest plugin  
(there is a patch for review for that).

Another thing we may want to consider is moving some more services into  
‘old’ node of the multinode setup. Specifically, dhcp and l3 agent (even  
for l3 legacy job). There are questions though whether we would then  
effectively hide some potential places to break (due to  
external-to-internal routing not leaving the node, or no tunneling needed  
between l3/dhcp and instances). So it may require introducing a separate  
‘networking’ node in the multinode setup to host l3/dhcp agents there.

==

We realize that subteam plans are not well known to other community  
members. We will work on raising awareness about use cases and features we  
target for next releases. That will include posting proper ‘ops oriented’  
RFEs, working on documentation (devref as well as networking-guide), etc.

One thing that we discussed on the event is updating networking-guide with  
detailed description of the upgrade process for neutron. We already have  
some pieces scattered there [f.e. we have some coverage for  
neutron-db-manage tool] but it’s nothing complete or deep enough. That’s  
something we will look into improving at the start of the N cycle.

==

As for actual coding, we focused on objects. We track the effort using  
‘ovo’ topic in gerrit:

https://review.openstack.org/#/q/topic:ovo

We landed some patches already, and we will land a lot more in the next  
months. Reviews from outside the subteam are highly appreciated. If  
anything, you may learn something new. :)

==

It was the second time we organized a highly focused sprint for Neutron  
(the previous one was on QoS during Liberty cycle). I hope we as a  
community start learning how to manage those events more effectively. I  
would be glad to talk about how the events go, what are the obstacles and  
mistakes we make along the line, if anything cares to hear. :) For example,  
the timing that we chose for this event this time was really unfortunate,  
and that slowed down some progress. Still, we are in a better shape coding  
wise as well as being on the same page for the upcoming work for the next 6  
months.

==

All in all, it was a great experience, and I look forward to continue the  
tradition of focused events in neutron community.

If you attended the event either IRL or virtually, and you have anything to  
point out that would help us to get it better next time, please don’t  
hesitate to comment. Feedback is very appreciated.

I also encourage other participants to comment on the report if I missed or  
mixed or messed something.

Ihar