Open Stack

On Wed, Jan 17, 2018 at 7:27 PM Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Hi all,
>

Hi!

>
> 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.


May I ask the reason for hosting this in the neutron tree?


> 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


Both legacy and new style (zuulv3) jobs rely on the same test matrix code,
so your change would impact both worlds consistently, which is good.


>
> (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.
>

Any other change worth mentioning?


>
> 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?
>

If understood properly it would still be possible to use the old names
right?
Some jobs may not rely on test matrix and just hard code the list of
services.
Such jobs would be broken otherwise.

What's the planned way forward towards removing the legacy lib?

Andrea Frittoli (andreaf)


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180119/79817ae3/attachment.html>