In [1] we removed the related jobs for these EOL releases. Here
we deal with removing code related to these branches including
any conditionals or special cases from emit releases and the
build-containers and run-test roles. Also removes some really
old references to newton.
[1] https://review.opendev.org/c/openstack/tripleo-ci/+/838110
Change-Id: I184cd525a8696b0b634ac8d6f895ab642ac5aa33
Assures consistent formatting of our python codebase without having
to rely on humans to do it, or to debate during reviews.
Change-Id: I1e62cc755fa60e453dea865f436241ecae330771
It's the first release that supports standalone and also LTS has not
change and it's still for queens only.
Story: https://tree.taiga.io/project/tripleo-ci-board/us/847
Change-Id: Id246cdab8a574ed57cd90813652532f47fbd0643
This also add dlrn_hash_newest variable to be able to make proper repo
switching.
The $title is just adding the necessary bits into emit_release to take
standalone_upgrade into account.
The dlrn_hash_newest is a forgotten variable from the initial emit
release. It has been included for standalone upgrade where the
problem first appeared, but will likely be needed for other upgrade
jobs as well when they switch to non specific release file.
Currently we only set dlrn_hash which becomes TRIPLEO_DLRN_REPO which
becomes delorean url. We don't do anything about dlrn_hash_tag_newest
which becomes RDO_DLRN_REPO which becomes delorean-current.
This means that when we are upgrading we get the dlrn_hash_tag_newest
that was defined in the previous run, ie during deployment.
Change-Id: I0e298fc37eb7b3fd0afaa13ab021330b789b2f5e
Closes-Bug: #1795367
It also calculates the releases with the emit releses script for fs047
Depends-On: Ic578de2237f9a43ff4fcd24141802a49a06be59c
Depends-On: https://review.openstack.org/#/c/605989/
Closes-Bug: 1792892
Change-Id: Ic1aea1052a9518999f0f02539459eeef516f9654
Currently, we are only able to upgrade TO a change under test. (n-1->n)
This change adds an argument (--upgrade-from), which allows for testing
that a change does not break upgrading FROM a release. (n->n+1)
The change itself is a no-op other than changing the signature of the
compose_releases_dictionary method.
Change-Id: I141aa5e01a097968a2a3427ebcfb5b8d304c9753
Currently, we do this in a combination of bash in this
repo and the release files themselves. However, as we begin
to support more different upgrade scenarios, this has proven
to be difficult to maintain.
Instead, we will use this python script to create a dictionary
of releases which describes which release will be used at each
point in the deploy: undercloud_install, undercloud_upgrade,
overcloud_deploy, and overcloud_upgrade.
This commit only provides an intial skeleton to work from.
Follow-up commits will provide:
1. The ability to get a DLRN hash for each of the above breakpoints
2. A CLI for the tool so it can be called from the TOCI scripts
3. The ability to parse a featureset config for upgrade variables
4. The ability to output the dictionary for consumption by TOCI scripts
Change-Id: Ibf61d7d12230f6714eb7dad91169aa043f5f8417
Ghanshyam Mann