> On Mar 18, 2016, at 4:01 AM, Ihar Hrachyshka <ihrac...@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”? 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
