-
Notifications
You must be signed in to change notification settings - Fork 65
Add all previous minor stable versions to current minor fast and stable #526
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add all previous minor stable versions to current minor fast and stable #526
Conversation
|
I thought about doing the same for 4.3 for benefit of the ~ 130 4.2 clusters that are still out there, but 4.2 is EOL and now even 4.3 is EOL. Additionally, adding older 4.2 into the 4.3 channels will require many additional blocks to be created because our edge management was much different back then. If we choose to pursue that we need to very carefully ensure that we're not introducing new edges, for instance 4.3.1 does include edges from 4.2.16 which would not currently be present in the graph but would if we were to backfill all stable 4.2.z into 4.3 channels. |
channels/fast-4.4.yaml
Outdated
|
|
||
| - 4.3.1 | ||
|
|
||
| - 4.3.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comparing:
$ for i in 3 4 5; do for weight in candidate fast stable; do FROM="${weight}-4.${i}"; TO="${weight}-4.$((i+1))"; diff -U0 --label "${FROM}" --label "${TO}" <(yaml2json < "channels/${FROM}.yaml" | jq -r '.versions[]' | grep "^4[.]${i}[.]" | sort -V) <(yaml2json < "channels/${TO}.yaml" | jq -r '.versions[]' | grep "^4[.]${i}[.]" | sort -V); done; done
--- candidate-4.3
+++ candidate-4.4
@@ -1,7 +0,0 @@
-4.3.0
-4.3.0-0.hotfix-2020-09-30-133631
-4.3.0-rc.0
-4.3.0-rc.3
-4.3.1
-4.3.2
-4.3.3
@@ -15,3 +8,3 @@
-4.3.14
-4.3.15
-4.3.17
+4.3.14+amd64
+4.3.15+amd64
+4.3.17+amd64
--- fast-4.3
+++ fast-4.4
@@ -2 +1,0 @@
-4.3.0-0.hotfix-2020-09-30-133631
--- stable-4.3
+++ stable-4.4
@@ -2 +1,0 @@
-4.3.0-0.hotfix-2020-09-30-133631
--- candidate-4.4
+++ candidate-4.5
@@ -1,17 +0,0 @@
-4.4.0
-4.4.0-rc.0
-4.4.0-rc.1
-4.4.0-rc.2
-4.4.0-rc.4
-4.4.0-rc.6
-4.4.0-rc.7
-4.4.0-rc.8
-4.4.0-rc.9
-4.4.0-rc.10
-4.4.0-rc.11
-4.4.0-rc.12
-4.4.0-rc.13
-4.4.2
-4.4.3
-4.4.4
-4.4.5
@@ -19 +1,0 @@
-4.4.7
--- candidate-4.5
+++ candidate-4.6
@@ -1,14 +0,0 @@
-4.5.0
-4.5.0-0.hotfix-2020-08-24-185832
-4.5.0-rc.1
-4.5.0-rc.2
-4.5.0-rc.4
-4.5.0-rc.5
-4.5.0-rc.6
-4.5.0-rc.7
-4.5.1
-4.5.1-rc.0
-4.5.2
-4.5.3
-4.5.4
-4.5.5
--- fast-4.5
+++ fast-4.6
@@ -1 +0,0 @@
-4.5.0-0.hotfix-2020-08-24-185832
@@ -10,0 +10 @@
+4.5.10
@@ -11,0 +12 @@
+4.5.12
--- stable-4.5
+++ stable-4.6
@@ -1,15 +0,0 @@
-4.5.0-0.hotfix-2020-08-24-185832
-4.5.1
-4.5.2
-4.5.3
-4.5.4
-4.5.5
-4.5.6
-4.5.7
-4.5.8
-4.5.9
-4.5.11
-4.5.13
-4.5.14
-4.5.15
-4.5.16But this is a step in the direction I want. However, I don't like violating candidate -> fast -> stable. Can we include these in candidate too to avoid:
$ diff -U0 --label candidate-4.3 --label fast-4.3 <(yaml2json <channels/candidate-4.4.yaml | jq -r '.versions[]' | sort -V) <(yaml2json <channels/fast-4.4.yaml | jq -r '.versions[]' | sort -V) | grep '^+\|---'
--- candidate-4.3
+++ fast-4.3
+4.3.0
+4.3.1
+4.3.2
+4.3.3and such?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#!/usr/bin/env python3
import functools
import re
import yaml
SEMVER = re.compile('^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$')
def version_key(v, minor):
match = SEMVER.match(v)
groups = match.groupdict()
v_minor = int(groups['minor'])
v_patch = int(groups['patch'])
if v_minor != minor:
v_patch = -v_patch
return (int(groups['major']), v_minor, v_patch, v)
data = {}
minors = [3,4,5]
weights = ['candidate', 'fast', 'stable']
for minor in minors:
data[minor] = {}
for weight in weights:
with open('channels/{}-4.{}.yaml'.format(weight, minor)) as f:
data[minor][weight] = yaml.safe_load(f)
for minor, next_minor in zip(minors, minors[1:]):
for weight in weights:
versions = set(data[minor][weight]['versions'])
versions.union(v for v in data[next_minor][weight]['versions'] if v.startswith('4.{}.'.format(minor)))
data[minor][weight]['versions'] = sorted(versions, key=functools.partial(version_key, minor=minor))
for minor in minors:
for weight in weights:
with open('channels/{}-4.{}.yaml'.format(weight, minor), 'w') as f:
yaml.safe_dump(data[minor][weight], f, default_flow_style=False)Strips comments (which I'm fine with), but I think something like this will do what I want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah i'm fine with ensuring that candidate always includes what's in fast and i'm fine with dropping all comments, don't know if i'll get to update this soon though, biggest thing for me is I'd like to get 4.6 channels (minus stable-4.6) squared away ASAP
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, 4.6 will need prompting forward a minor. I'll update my script...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I bumped my script and pushed a fixup to your branch. If it looks good, squash it in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
although we might want to run the script fresh on master to pick up #508 and similar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you fill out fast-4.6 with 4.5.z versions as well? We'll withold from stable-4.6 until upgrades are ready to go stable.
0c26fb8 to
4a6067e
Compare
Today there's much confusion and uncertainty about the upgrade process due to multiple factors. This may lead some people to switch to the next channel before they're able to upgrade to the next minor. If they were on a version that's not in the next channel they may be presented no upgrade paths even if application of an additional z-stream update would unlock a minor upgrade. Hopefully this shouldn't be necessary when we push 4.7 out because the CVO now knows which additional channels contain the current version enablign the console to only present those channels when appropriate discouraging people from changing prematurely.
…and stable
Generated with the following script:
import functools
import re
import yaml
SEMVER = re.compile('^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$')
def version_key(v, minor):
match = SEMVER.match(v)
groups = match.groupdict()
v_minor = int(groups['minor'])
v_patch = int(groups['patch'])
if v_minor != minor:
v_patch = -v_patch
return (int(groups['major']), v_minor, v_patch, v)
data = {}
minors = [3, 4, 5, 6]
weights = ['candidate', 'fast', 'stable']
for minor in minors:
data[minor] = {}
for weight in weights:
with open('channels/{}-4.{}.yaml'.format(weight, minor)) as f:
data[minor][weight] = yaml.safe_load(f)
for minor, next_minor in zip(minors, minors[1:]):
for weight in weights:
versions = set(data[minor][weight]['versions'])
versions.union(v for v in data[next_minor][weight]['versions'] if v.startswith('4.{}.'.format(minor)))
data[minor][weight]['versions'] = sorted(versions, key=functools.partial(version_key, minor=minor))
versions = set(data[next_minor][weight]['versions'])
versions.union(v for v in data[minor][weight]['versions'] if v.startswith('4.{}.'.format(minor)))
data[next_minor][weight]['versions'] = sorted(versions, key=functools.partial(version_key, minor=next_minor))
for minor in minors:
for weight in weights:
with open('channels/{}-4.{}.yaml'.format(weight, minor), 'w') as f:
yaml.safe_dump(data[minor][weight], f, default_flow_style=False)
4a6067e to
14085d7
Compare
stable-4.6 will come after we promote upgrades to stable channel
|
@wking PTAL again even though most changes came from you :-) |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LalatenduMohanty, sdodson 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 |
|
/hold cancel |
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).
|
Some follow-up in #549 |
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).
Like afa003f (Populate 4.5.z into candidate-4.6 and fast-4.6, 2020-11-05, openshift#526), but for 4.7.
Like afa003f (Populate 4.5.z into candidate-4.6 and fast-4.6, 2020-11-05, openshift#526), but for 4.7. Also backfill a few 4.6.z into candidate-4.7, because we don't want releases in fast-4.7 that aren't in candidate-4.7.
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
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
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
Today there's much confusion and uncertainty about the upgrade process
due to multiple factors. This may lead some people to switch to the next
channel before they're able to upgrade to the next minor. If they were on
a version that's not in the next channel they may be presented no upgrade
paths even if application of an additional z-stream update would unlock
a minor upgrade.
Hopefully this shouldn't be necessary when we push 4.7 out because the CVO
now knows which additional channels contain the current version enablign the
console to only present those channels when appropriate discouraging people
from changing prematurely.
/cc @wking