Hi all, 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. 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 (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. 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? Thanks for attention, Ihar __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
