Where to put a zuul patch (etherpad)
At any place in the playbooks where we have a call to repo-setup
role, we will also have a call to install-built-repo role (guarded
by a when condition). Each of these places in code will have a
unique name derived from where it is (the places linked in "current
status" section could be called undercloud_deploy,
overcloud_deploy, undercloud_mixed_upgrade).
-
Create a
zuul_repo_enabled_atvariable. It's an array, multiple values are allowed. It is set in a featureset yaml file, its value must be a subset of the uniqueinstall-built-repopoints mentioned above. The default value is ['undercloud_deploy', 'overcloud_deploy'] which should work nicely for normal deploy jobs. We only execute theinstall-built-reporole at the spots which are in thezuul_repo_enabled_atlist. -
Add more insertion points than we have now, e.g.
undercloud_mixed_updatefor minor update jobs, currently in minor updates we can just go from current+zuul to current+zuul. -
With full switch to containers, a critical part of success will be inserting the zuul changes into container images. This is a big chunk of additional work, but i think driving the decision "when to use images with zull changes vs. without zuul changes" with the
zuul_repo_enabled_atvariable should be still valid. -
gate jobs for upgrade
-
libvirt reproducer CI
- Q: ovb reproducer CI has been suggested to be 'hard' what are the gaps?
- We could avoid a bunch of work if we could launch tasks direclty on the libvirt host
- ansible playbook
- swarm plugin (https://wiki.jenkins.io/display/JENKINS/Swarm+Plugin)
- other supported Central CI tenant
- ci.centos.org is likely an idea target
- prefer to not use our own existing HW or nested virt (central CI tenant)
one of the reasons why the upgrade team wants the capability to inject repos at multiple places/phases is that they want to add a variety of new jobs
- pike --> queens
- queens --> rocky
-
Let: Change is in queens... (P->Q)
-
Let: containers are always updated (might not be true today)
-
"If we have repo-setup and install-built-repo.."
- when we call upgrade w/ "QUEENS"
- update UC
- update OC repos
- update containers
- in this case install built repo will run because there's a match on "change is in queens" predicate of python tool
- when we call upgrade w/ "QUEENS"
-
Bigger challange...Mixed Upgrade (see (etherpad) @ L64+)
- would like to avoid calling this a "tech debt sprint"
- this seems like a "jumble" of tasks that are not related to a specific epic
- if we think about all changes being packaged into RPM's, yum manages having rpm's updated in the correct places
- ensure repos are in place (yay sprint 13...makes this simpler)
- would be great to have visual aids that help to show how upgrade/update CI is working
- some diagrams / line charts (e.g. Google Draw)
- open question: for just our team vs. "time to communicate to community" ?
-
Generate diagram for team (ahead of sprint planning)
- this is to have discussion, and is a starting point. we can polish later.
- can be used as a framework for testing / validation.
- TC: this is a complex workflow + complex design, clarity will pay dividends here. It's worth it
-
jobs 37, 50, $newThing in place and voting
$newThing := "keystone only upgrade"
-
makeing sure repo-setup and build-test-change bits/roles/playbooks are working
- gives us protections to make changes for (etherpad) safely
- simple things are not always simple
- we had unknown unknowns coming into this sprint
Internal Software Factory! (rhinternal zuul v3
- bringing up additional jobs
- RDO on RHEL images and containers
- Building OSP images and containers (reldel work under way)
- refactoring TOCI work in a controllable safe place
- zuul v3
- mad hacking / prototyping on python release tool
- we do need to excercise caution so we don't break the world