<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 19, 2018 at 8:36 PM Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andrea,<br>
<br>
thanks for taking time to reply. I left some answers inline.<br>
<br>
On Fri, Jan 19, 2018 at 9:08 AM, Andrea Frittoli<br>
<<a href="mailto:andrea.frittoli@gmail.com" target="_blank">andrea.frittoli@gmail.com</a>> wrote:<br>
><br>
><br>
> On Wed, Jan 17, 2018 at 7:27 PM Ihar Hrachyshka <<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
><br>
><br>
> Hi!<br>
>><br>
>><br>
>> tl;dr I propose to switch to lib/neutron devstack library in Queens. I<br>
>> ask for buy-in to the plan from release and QA teams, something that<br>
>> infra asked me to do.<br></blockquote><div><br></div><div>Hello Ihar, </div><div><br></div><div>I'm coming back to this thread after a while, since I'm writing zuulv3 native devstack jobs,</div><div>and I think this is the perfect opportunity for starting to using lib/neutron, since we easily</div><div>decide to limit the change to the branches we want, e.g. start with master and then</div><div>go back to stable/queens if we want to.</div><div><br></div><div>Zuulv3 native jobs run on master, queens and they're being ported to Pike.</div><div>Starting from Queens on I plan to stop using the test-matrix from devstack-gate, and define<br></div><div>the list of required services in jobs instead. This is made possible by the job inheritance</div><div>capability introduced by Zuul v3. For the single node job I proposed a change already [0],</div><div>and I'm working on the same for multinode. I would like if possible to start using new service</div><div>and variable names as part of [0] but I need some help on that.</div><div><br></div><div>This change in the zuulv3 jobs should replace the existing in progress devstack-gate patch [1].</div><div><br></div><div>If you are at the PTG I would be happy to chat / hack on this topic there.</div><div><br></div><div>Andrea Frittoli (andreaf)</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/545633/">https://review.openstack.org/#/c/545633/</a> </div><div>[1] <a href="https://review.openstack.org/#/c/436798">https://review.openstack.org/#/c/436798</a> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>><br>
>> ===<br>
>><br>
>> Last several cycles we were working on getting lib/neutron - the new<br>
>> in-tree devstack library to deploy neutron services - ready to deploy<br>
>> configurations we may need in our gates.<br>
><br>
><br>
> May I ask the reason for hosting this in the neutron tree?<br>
<br>
Sorry for wording it in a misleading way. The lib/neutron library is<br>
in *devstack* tree:<br>
<a href="https://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron" rel="noreferrer" target="_blank">https://git.openstack.org/cgit/openstack-dev/devstack/tree/lib/neutron</a><br>
So in terms of deployment dependencies, there are no new repositories<br>
to fetch from or gate against.<br>
<br>
><br>
>><br>
>> Some pieces of the work<br>
>> involved can be found in:<br>
>><br>
>> <a href="https://review.openstack.org/#/q/topic:new-neutron-devstack-in-gate" rel="noreferrer" target="_blank">https://review.openstack.org/#/q/topic:new-neutron-devstack-in-gate</a><br>
>><br>
>> I am happy to announce that the work finally got to the point where we<br>
>> can consistently pass both devstack-gate and neutron gates:<br>
>><br>
>> (devstack-gate) <a href="https://review.openstack.org/436798" rel="noreferrer" target="_blank">https://review.openstack.org/436798</a><br>
><br>
><br>
> Both legacy and new style (zuulv3) jobs rely on the same test matrix code,<br>
> so your change would impact both worlds consistently, which is good.<br>
><br>
>><br>
>><br>
>> (neutron) <a href="https://review.openstack.org/441579" rel="noreferrer" target="_blank">https://review.openstack.org/441579</a><br>
>><br>
>> One major difference between the old lib/neutron-legacy library and<br>
>> the new lib/neutron one is that service names for neutron are<br>
>> different. For example, q-svc is now neutron-api, q-dhcp is now<br>
>> neutron-dhcp, etc. (In case you wonder, this q- prefix links us back<br>
>> to times when Neutron was called Quantum.) The way lib/neutron is<br>
>> designed is that whenever a single q-* service name is present in<br>
>> ENABLED_SERVICES, the old lib/neutron-legacy code is triggered to<br>
>> deploy services.<br>
>><br>
>> Service name changes are a large part of the work. The way the<br>
>> devstack-gate change linked above is designed is that it changes names<br>
>> for deployed neutron services starting from Queens (current master),<br>
>> so old branches and grenade jobs are not affected by the change.<br>
><br>
><br>
> Any other change worth mentioning?<br>
><br>
<br>
The new library is a lot more simplified and opinionated and has fewer<br>
knobs and branching that is not very useful for majority of users.<br>
lib/neutron-legacy was always known for its complicated configuration.<br>
We hope that adopting the new library will unify and simplify neutron<br>
configuration across different jobs and setups.<br>
<br>
>From consumer perspective, nothing should change expect service names.<br>
Some localrc files may need adoption if they rely on old arcane knobs.<br>
It can be done during transition phase since old service names are<br>
expected to work.<br>
<br>
>><br>
>><br>
>> While we validated the change switching to new names against both<br>
>> devstack-gate and neutron gates that should cover 90% of our neutron<br>
>> configurations, and followed up with several projects that - we<br>
>> induced - may be affected by the change - there is always a chance<br>
>> that some job in some project gate would fail because of it, and we<br>
>> would need to push a (probably rather simple) follow-up to unbreak the<br>
>> affected job. Due to the nature of the work, the span of impact, and<br>
>> the fact that infra repos are not easily gated against with Depends-On<br>
>> links, we may need to live with the risk.<br>
>><br>
>> Of course, there are several aspects of the project life involved,<br>
>> including QA and release delivery efforts. I was advised to reach out<br>
>> to both of those teams to get a buy-in to proceed with the move. If we<br>
>> have support for the switch now, as per Clark, infra is ready to<br>
>> support the switch.<br>
>><br>
>> Note that the effort span several cycles, partially due to low review<br>
>> velocity in several affected repos (devstack, devstack-gate),<br>
>> partially because new changes in all affected repos were pulling us<br>
>> back from the end goal. This is one of the reasons why I would like us<br>
>> to do the switch sooner rather than later, since chasing this moving<br>
>> goalpost became rather burdensome.<br>
>><br>
>> What are QA and release team thoughts on the switch? Are we ready to<br>
>> do it in next weeks?<br>
><br>
><br>
> If understood properly it would still be possible to use the old names<br>
> right?<br>
> Some jobs may not rely on test matrix and just hard code the list of<br>
> services.<br>
> Such jobs would be broken otherwise.<br>
><br>
> What's the planned way forward towards removing the legacy lib?<br>
<br>
Yes, they should still work.<br>
<br>
My plan is to complete switch of devstack-gate to new names; once we<br>
are sure all works as expected, we can proceed with replacing all q-*<br>
service names still captured by <a href="http://codesearch.openstack.org" rel="noreferrer" target="_blank">codesearch.openstack.org</a> with new<br>
names; finally, remove lib/neutron-legacy in Rocky. (Note that the old<br>
library already issues a deprecation warning since Newton:<br>
<a href="https://review.openstack.org/#/c/315806/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/315806/</a>)<br>
<br>
Ihar<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div>