Open Stack

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