Open Stack

On Fri, Jan 19, 2018 at 8:36 PM Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> Hi Andrea,
>
> thanks for taking time to reply. I left some answers inline.
>
> On Fri, Jan 19, 2018 at 9:08 AM, Andrea Frittoli
> <andrea.frittoli at gmail.com> wrote:
> >
> >
> > 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.
>

Hello Ihar,

I'm coming back to this thread after a while, since I'm writing zuulv3
native devstack jobs,
and I think this is the perfect opportunity for starting to using
lib/neutron, since we easily
decide to limit the change to the branches we want, e.g. start with master
and then
go back to stable/queens if we want to.

Zuulv3 native jobs run on master, queens and they're being ported to Pike.
Starting from Queens on I plan to stop using the test-matrix from
devstack-gate, and define
the list of required services in jobs instead. This is made possible by the
job inheritance
capability introduced by Zuul v3. For the single node job I proposed a
change already [0],
and I'm working on the same for multinode. I would like if possible to
start using new service
and variable names as part of [0] but I need some help on that.

This change in the zuulv3 jobs should replace the existing in progress
devstack-gate patch [1].

If you are at the PTG I would be happy to chat / hack on this topic there.

Andrea Frittoli (andreaf)

[0] https://review.openstack.org/#/c/545633/
[1] https://review.openstack.org/#/c/436798


> >>
> >> ===
> >>
> >> 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?
>
> Sorry for wording it in a misleading way. The lib/neutron library is
> in *devstack* tree:
> https://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron
> So in terms of deployment dependencies, there are no new repositories
> to fetch from or gate against.
>
> >
> >>
> >> 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?
> >
>
> The new library is a lot more simplified and opinionated and has fewer
> knobs and branching that is not very useful for majority of users.
> lib/neutron-legacy was always known for its complicated configuration.
> We hope that adopting the new library will unify and simplify neutron
> configuration across different jobs and setups.
>
> From consumer perspective, nothing should change expect service names.
> Some localrc files may need adoption if they rely on old arcane knobs.
> It can be done during transition phase since old service names are
> expected to work.
>
> >>
> >>
> >> 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?
>
> Yes, they should still work.
>
> My plan is to complete switch of devstack-gate to new names; once we
> are sure all works as expected, we can proceed with replacing all q-*
> service names still captured by codesearch.openstack.org with new
> names; finally, remove lib/neutron-legacy in Rocky. (Note that the old
> library already issues a deprecation warning since Newton:
> https://review.openstack.org/#/c/315806/)
>
> 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/20180223/196091bd/attachment.html>