This sounds great Ihar! Let us know when we should make the changes to the neutron-lbaas projects.
Michael On Wed, Jan 17, 2018 at 11:26 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote: > Hi all, > > tl;dr I propose to switch to lib/neutron devstack library in Queens. I > ask for buy-in to the plan from release and QA teams, something that > infra asked me to do. > > === > > Last several cycles we were working on getting lib/neutron - the new > in-tree devstack library to deploy neutron services - ready to deploy > configurations we may need in our gates. Some pieces of the work > involved can be found in: > > https://review.openstack.org/#/q/topic:new-neutron-devstack-in-gate > > I am happy to announce that the work finally got to the point where we > can consistently pass both devstack-gate and neutron gates: > > (devstack-gate) https://review.openstack.org/436798 > (neutron) https://review.openstack.org/441579 > > One major difference between the old lib/neutron-legacy library and > the new lib/neutron one is that service names for neutron are > different. For example, q-svc is now neutron-api, q-dhcp is now > neutron-dhcp, etc. (In case you wonder, this q- prefix links us back > to times when Neutron was called Quantum.) The way lib/neutron is > designed is that whenever a single q-* service name is present in > ENABLED_SERVICES, the old lib/neutron-legacy code is triggered to > deploy services. > > Service name changes are a large part of the work. The way the > devstack-gate change linked above is designed is that it changes names > for deployed neutron services starting from Queens (current master), > so old branches and grenade jobs are not affected by the change. > > While we validated the change switching to new names against both > devstack-gate and neutron gates that should cover 90% of our neutron > configurations, and followed up with several projects that - we > induced - may be affected by the change - there is always a chance > that some job in some project gate would fail because of it, and we > would need to push a (probably rather simple) follow-up to unbreak the > affected job. Due to the nature of the work, the span of impact, and > the fact that infra repos are not easily gated against with Depends-On > links, we may need to live with the risk. > > Of course, there are several aspects of the project life involved, > including QA and release delivery efforts. I was advised to reach out > to both of those teams to get a buy-in to proceed with the move. If we > have support for the switch now, as per Clark, infra is ready to > support the switch. > > Note that the effort span several cycles, partially due to low review > velocity in several affected repos (devstack, devstack-gate), > partially because new changes in all affected repos were pulling us > back from the end goal. This is one of the reasons why I would like us > to do the switch sooner rather than later, since chasing this moving > goalpost became rather burdensome. > > What are QA and release team thoughts on the switch? Are we ready to > do it in next weeks? > > Thanks for attention, > 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