Open Stack

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 <ihrachys at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev