Open Stack

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