Open Stack

On 03/21/2016 07:11 AM, Doug Wiegley wrote:
> 
>> On Mar 18, 2016, at 4:01 AM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:
>>
>> 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.]
> 
> What is the plan for out of tree objects derived from neutron, and out of tree projects that are using the current neutron objects?  Specifically, the ones which *can’t* use the REST API, because they’re for something loaded directly into neutron-server (core plugins, service plugins, etc). Will they work?  Is our live upgrade strategy going to be labeled “reference only”?
> 

That's a good point. Ideally plugins should use objects too. Once we
have objects in the core code base it should be easy to introduce them
in the plugins. In most cases we probably won't have to change anything
in the plugins code, since objects can be accessed as dict. We have
started this effort very early in the release cycle, so my hope is that
we will have enough time to test and make required changes.

cheers,

Rossella

> doug
> 
> 
>>
>> 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
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>