<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 17, 2018 at 7:27 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 all,<br></blockquote><div><br></div><div>Hi! </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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>
<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. </blockquote><div><br></div><div>May I ask the reason for hosting this in the neutron tree?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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></blockquote><div><br></div><div>Both legacy and new style (zuulv3) jobs rely on the same test matrix code,</div><div>so your change would impact both worlds consistently, which is good.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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></blockquote><div><br></div><div>Any other change worth mentioning? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></blockquote><div><br></div><div>If understood properly it would still be possible to use the old names right?</div><div>Some jobs may not rely on test matrix and just hard code the list of services.</div><div>Such jobs would be broken otherwise.</div><div><br></div><div>What's the planned way forward towards removing the legacy lib?</div><div><br></div><div>Andrea Frittoli (andreaf)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks for attention,<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>