channels: More backfilling (e.g. 4.3.0 in candidate-4.4) #549
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Following up on 646535a (Add all previous minor stable versions to current minor fast and stable, 2020-10-29, openshift#526) with improved backfilling logic. The idea is that all previous-minor releases in the previous minor's branch of the same weight are in your branch (e.g. 4.3.0 is in candidate-4.3, so it gets backfilled into candidate-4.4). And all current-minor releases in the next-minor's branch of the same weight are in your branch (e.g. if 4.5.0 was in candidate-4.6, it would be backfilled into candidate-4.5, but currently no changes from this logic).
openshift-ci-robot
requested review from
LalatenduMohanty and
derekwaynecarr
openshift-ci-robot
added
the
approved
sdodson
reviewed
Nov 12, 2020
sdodson
reviewed
Nov 12, 2020
Generated with: $ hack/backfill.py $ git checkout HEAD -- channels/candidate-4.3.yaml $ emacs channels/candidate-4.4.yaml $ git checkout HEAD -- channels/stable-4.6.yaml With the candidate-4.3 and 4.4 massaging so we don't get: - 4.3.14 +- 4.3.14+amd64 and similar, where all arches went into candidate-4.3, but only amd64 went into the candidate-4.4, 5ff491a (Enable 4.3.14 in candidate channel(s), 2020-04-22, openshift#193). The stable-4.6 massaging is because we are delaying the 4.5->4.6 stable updates while we convince ourselves that fast traffic is sufficiently reliable.
wking
force-pushed
the
more-backfilling
branch
from
6408ba1 to
1d9fe0f
Compare
Member
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: sdodson, wking The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Apr 1, 2021
These were supposed to be tombstoned in candidate based on recycled errata [1,2]. But they snuck into fast-4.6 with afa003f (Populate 4.5.z into candidate-4.6 and fast-4.6, 2020-11-05, openshift#526). And then I moved them from there into fast-4.5 with 1d9fe0f (channels: More backfilling (e.g. 4.3.0 in candidate-4.4), 2020-11-12, openshift#549). And they went into stable-4.6 with 1fb8768 (Add 4.5 to 4.6 upgrades to stable-4.6, 2020-12-14, openshift#585). This commit completes their accidental journey, since tombstoning them in fast would violate [3]: While the fast-4.5 channel contains releases as soon as their errata are published, releases are added to the stable-4.5 channel after a delay [1]: openshift#438 (comment) [2]: openshift#456 (comment) [3]: https://docs.openshift.com/container-platform/4.5/updating/updating-cluster-between-minor.html#stable-4-5-channel
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Apr 13, 2021
These were supposed to be tombstoned in candidate based on recycled errata [1,2]. But they snuck into fast-4.6 with afa003f (Populate 4.5.z into candidate-4.6 and fast-4.6, 2020-11-05, openshift#526). And then I moved them from there into fast-4.5 with 1d9fe0f (channels: More backfilling (e.g. 4.3.0 in candidate-4.4), 2020-11-12, openshift#549). And they went into stable-4.6 with 1fb8768 (Add 4.5 to 4.6 upgrades to stable-4.6, 2020-12-14, openshift#585). This commit completes their accidental journey, since tombstoning them in fast would violate [3]: While the fast-4.5 channel contains releases as soon as their errata are published, releases are added to the stable-4.5 channel after a delay [1]: openshift#438 (comment) [2]: openshift#456 (comment) [3]: https://docs.openshift.com/container-platform/4.5/updating/updating-cluster-between-minor.html#stable-4-5-channel
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Apr 17, 2021
These were supposed to be tombstoned in candidate based on recycled errata [1,2]. But they snuck into fast-4.6 with afa003f (Populate 4.5.z into candidate-4.6 and fast-4.6, 2020-11-05, openshift#526). And then I moved them from there into fast-4.5 with 1d9fe0f (channels: More backfilling (e.g. 4.3.0 in candidate-4.4), 2020-11-12, openshift#549). And they went into stable-4.6 with 1fb8768 (Add 4.5 to 4.6 upgrades to stable-4.6, 2020-12-14, openshift#585). This commit completes their accidental journey, since tombstoning them in fast would violate [3]: While the fast-4.5 channel contains releases as soon as their errata are published, releases are added to the stable-4.5 channel after a delay [1]: openshift#438 (comment) [2]: openshift#456 (comment) [3]: https://docs.openshift.com/container-platform/4.5/updating/updating-cluster-between-minor.html#stable-4-5-channel
wking
added a commit
to wking/cincinnati-graph-data
that referenced
this pull request
Sep 3, 2021
When we have a GitHub token, we checkout a branch and create a pull request for each promotion. When we don't have a token, we used to just log the changes that needed to happen. With this commit, a token-less call will now edit the local files to perform all appropriate promotions. That allows this script (which understands about tombstones and filters and other promotion criteria) to be used to backfill channels when we expand filters (e.g. allowing 4.(y-1) in fast-4.y after 4.y GAs, or allowing 4.(y-1) in stable-4.y after we feel comfortable with the fast behavior. That should make things like 8da5782 (4.8 GA -- Fill in 4.7.z into fast-4.8, 2021-07-26, openshift#947)'s accidental promotion of the tombstoned 4.7.10 and similar less likely. More on that in 4c53c7b (Blocking all the incoming edges to 4.7.10, 4.7.14, 4.7.15, 4.7.20, 2021-09-03, openshift#1035). Drop the old backfill script from 2a02325 (hack/backfill: Add a backfilling script, 2020-11-12, openshift#549), now that this new functionality makes it obsolete.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Generated with:
With the candidate-4.3 and 4.4 massaging so we don't get:
- 4.3.14 +- 4.3.14+amd64and similar, where all arches went into candidate-4.3, but only amd64 went into the candidate-4.4, 5ff491a (#193).