Hi, As many of you may recall, our plan to migrate the devstack jobs to Zuul v3 was to gradually convert pieces of the existing devstack-gate script to Ansible roles which would be shared between the Ansible run inside the devstack-gate script and the Ansible run by Zuul v3. Eventually, the idea was that the devstack-gate script would be functionally very similar to Zuul v3, and replacement would be easy.
Unfortunately, not enough of that work is completed for us to be able to effect the transition in that manner. We could continue in that direction, however we would certainly miss our target of a PTG cutover. Instead, in an attempt to meet that deadline, I propose the following: We create a devstack-legacy job in Zuul v3 which attempts to run devstack-gate in the manner closest to that in which it runs today. This means that it will use the Zuul-provided git repos rather than performing its own git fetch operations, and supply config files and environment variables which are compatible with the way Zuul v2 works. Simultaneously, we also create a new devstack job which utilizes all the new features of Zuul v3 and is structured in the way we envisioned earlier. We can start very simply here and avoid carrying all of the design baggage from the earlier job. This will be a job that projects can build off of and migrate to over time, once we have completed the migration. During the migration itself, we automatically convert all of the devstack jobs to use the devstack-legacy job framework. Fortunately, we have completed (and are still continuing) some significant work on the Ansiblification of the current devstack-gate job (thanks!). That has already allowed us to copy some of those roles into the base job and made some features previously only available to devstack available to all jobs. We should continue the work in progress there, but I don't think we should expect the two jobs to directly share those roles. To that end, we should keep the v2 devstack-gate roles in the playbooks/roles/ directory, but as we create v3 versions of the roles, place them in the top-level roles/ directory. These roles will be somewhat duplicative, but this will allow us to fully separate the two sets of jobs which will allow us to work on the v3 versions of the roles without having to worry about maintaining compatability, and to finish the legacy version of the job quickly. -Jim _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
