On Fri, Jan 19, 2018 at 8:36 PM Ihar Hrachyshka <[email protected]> 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 > <[email protected]> wrote: > > > > > > On Wed, Jan 17, 2018 at 7:27 PM Ihar Hrachyshka <[email protected]> > 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
