Re: [OpenStack-Infra] Plan for devstack Zuul v3 jobs
David Moreau Simard writes: > I'm OK with this. > Should we get to a point where the scripts can be used by both Zuul v2 > and Zuul v3 simultaneously so that there is no "migration" or "cutover" so > to speak ? > > It might mean some amount of work but it shouldn't be too bad, I think ? > Ansible (Zuul v3) will potentially end up running Ansible but we've seen > worse and it'll be temporary. > > It would allow for a smooth transition because we would just essentially > stop running the v2 jobs when we are ready. Yes, I'm working on that in this series of changes to create the devstack-legacy job: https://review.openstack.org/497699 However, there will still be work for the migration script to do. Essentially, the JJB shell snippet will need to be transformed into a Zuul job variable, the usage of the local_conf macro transformed into a different job variable, and any projects which appear in "PROJECTS=..." variable assignments in the job shell will need to be detected and added to the required-projects job attribute. I believe these are all relatively straightforward transformations. -Jim ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Plan for devstack Zuul v3 jobs
On Fri, Aug 25, 2017 at 4:50 PM, James E. Blair wrote: > 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. I'm OK with this. Should we get to a point where the scripts can be used by both Zuul v2 and Zuul v3 simultaneously so that there is no "migration" or "cutover" so to speak ? It might mean some amount of work but it shouldn't be too bad, I think ? Ansible (Zuul v3) will potentially end up running Ansible but we've seen worse and it'll be temporary. It would allow for a smooth transition because we would just essentially stop running the v2 jobs when we are ready. David Moreau Simard Senior Software Engineer | OpenStack RDO dmsimard = [irc, github, twitter] ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Plan for devstack Zuul v3 jobs
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 OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra