Open Stack

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