Skip to content

Conversation

@sdodson
Copy link
Member

@sdodson sdodson commented Oct 29, 2020

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

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 29, 2020
@sdodson
Copy link
Member Author

sdodson commented Oct 29, 2020

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.


- 4.3.1

- 4.3.0
Copy link
Member

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.16

But 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.3

and such?

Copy link
Member

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.

Copy link
Member Author

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

Copy link
Member

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...

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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.

@wking wking force-pushed the backfill-stable-previous-minors branch from 0c26fb8 to 4a6067e Compare November 3, 2020 05:40
sdodson and others added 2 commits November 5, 2020 15:29
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)
@sdodson sdodson force-pushed the backfill-stable-previous-minors branch from 4a6067e to 14085d7 Compare November 5, 2020 20:30
stable-4.6 will come after we promote upgrades to stable channel
@sdodson
Copy link
Member Author

sdodson commented Nov 5, 2020

@wking PTAL again even though most changes came from you :-)

@LalatenduMohanty
Copy link
Member

/lgtm
/hold for @wking to take a look

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 9, 2020
@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Nov 9, 2020
@openshift-ci-robot
Copy link

[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

Details Needs approval from an approver in each of these files:
  • OWNERS [LalatenduMohanty,sdodson]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@LalatenduMohanty
Copy link
Member

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Nov 9, 2020
@openshift-merge-robot openshift-merge-robot merged commit 0d96095 into openshift:master Nov 9, 2020
wking added a commit to wking/cincinnati-graph-data that referenced this pull request Nov 12, 2020
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).
@wking
Copy link
Member

wking commented Nov 12, 2020

Some follow-up in #549

sdodson pushed a commit to sdodson/cincinnati-graph-data that referenced this pull request Dec 3, 2020
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).
wking added a commit to wking/cincinnati-graph-data that referenced this pull request Feb 24, 2021
Like afa003f (Populate 4.5.z into candidate-4.6 and fast-4.6,
2020-11-05, openshift#526), but for 4.7.
wking added a commit to wking/cincinnati-graph-data that referenced this pull request Feb 24, 2021
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.
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants