ci-operator/step-registry/ipi/install: Remove ClusterVersion channel #8631
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
openshift-ci-robot
added
the
do-not-merge/work-in-progress
openshift-ci-robot
added
the
approved
wking
changed the title
Member
Author
|
Success: $ curl -s https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_release/8631/rehearse-8631-pull-ci-cri-o-cri-o-release-1.13-e2e-aws/1/artifacts/e2e-aws/gather-extra/clusterversion.json | jq -r '.items[].spec'
{
"clusterID": "2956a881-465c-478d-9874-bb9c524c1860",
"upstream": "https://api.openshift.com/api/upgrades_info/v1/graph"
}I will try and extend this to our other templates as well, but there's no reason we can't land this as it stands and hit the rest in follow-up work. |
CI and nightly releases are not part of the official Red Hat Cincinnati graphs. This commit removes the channel property [1], which will result in the NoChannel condition [2], but will keep the CVO from attempting to find its current version in the official Cincinnati [3]. That in turn should keep the CVO from throwing a new, critical alert [4], which will keep it from running afoul of recent update e2e logic that forbids critical alerts [5]. [1]: https://github.com/openshift/installer/blob/4eca2efd615f8abd65f576721e2410b19f0d40d0/data/data/manifests/bootkube/cvo-overrides.yaml.template#L8 [2]: https://github.com/openshift/cluster-version-operator/blob/fa452c2d270f1f989f3868ef97ae8cf825713583/docs/user/status.md#nochannel [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1827378#c4 [4]: openshift/cluster-version-operator#357 [5]: openshift/origin#24786
Member
Author
|
I've pushed cfe68a5ca7 -> f3c6b90, adding this after all |
Member
Author
|
Looked over the failures so far; nothing looks like something due to me clearing the channel (or accidentally flubbing the shell). |
Contributor
|
@wking: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
Member
Author
|
Go away WIP label! /retitle ci-operator/step-registry/ipi/install: Remove ClusterVersion channel |
openshift-ci-robot
changed the title
openshift-ci-robot
removed
the
do-not-merge/work-in-progress
Contributor
|
/lgtm |
Contributor
|
/retest |
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jottofar, 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 |
Contributor
|
@wking: Updated the following 31 configmaps:
DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
spadgett
added a commit
to spadgett/console
that referenced
this pull request
May 4, 2020
Update Channel will no longer be set in CI. Don't fail the test if it's `Not available`. See openshift/release#8631
stbenjam
added a commit
to stbenjam/dev-scripts
that referenced
this pull request
Jun 3, 2021
CI and nightly releases are not part of the official Red Hat Cincinnati graphs. This commit removes the channel property [1], which will result in the NoChannel condition [2], but will keep the CVO from attempting to find its current version in the official Cincinnati [3]. That in turn should keep the CVO from throwing a new, critical alert [4], which will keep it from running afoul of recent update e2e logic that forbids critical alerts [5]. See this related PR [6] which does this for other platforms IPI install step. [1]: https://github.com/openshift/installer/blob/4eca2efd615f8abd65f576721e2410b19f0d40d0/data/data/manifests/bootkube/cvo-overrides.yaml.template#L8 [2]: https://github.com/openshift/cluster-version-operator/blob/fa452c2d270f1f989f3868ef97ae8cf825713583/docs/user/status.md#nochannel [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1827378#c4 [4]: openshift/cluster-version-operator#357 [5]: openshift/origin#24786 [6]: openshift/release#8631
stbenjam
added a commit
to stbenjam/dev-scripts
that referenced
this pull request
Jun 3, 2021
CI and nightly releases are not part of the official Red Hat Cincinnati graphs. This commit removes the channel property [1], which will result in the NoChannel condition [2], but will keep the CVO from attempting to find its current version in the official Cincinnati [3]. That in turn should keep the CVO from throwing a new, critical alert [4], which will keep it from running afoul of recent update e2e logic that forbids critical alerts [5]. See this related PR [6] which does this for other platforms IPI install step. [1]: https://github.com/openshift/installer/blob/4eca2efd615f8abd65f576721e2410b19f0d40d0/data/data/manifests/bootkube/cvo-overrides.yaml.template#L8 [2]: https://github.com/openshift/cluster-version-operator/blob/fa452c2d270f1f989f3868ef97ae8cf825713583/docs/user/status.md#nochannel [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1827378#c4 [4]: openshift/cluster-version-operator#357 [5]: openshift/origin#24786 [6]: openshift/release#8631 Co-authored-by: W. Trevor King <wking@tremily.us>
openshift-merge-robot
pushed a commit
to openshift-metal3/dev-scripts
that referenced
this pull request
Sep 23, 2021
CI and nightly releases are not part of the official Red Hat Cincinnati graphs. This commit removes the channel property [1], which will result in the NoChannel condition [2], but will keep the CVO from attempting to find its current version in the official Cincinnati [3]. That in turn should keep the CVO from throwing a new, critical alert [4], which will keep it from running afoul of recent update e2e logic that forbids critical alerts [5]. See this related PR [6] which does this for other platforms IPI install step. [1]: https://github.com/openshift/installer/blob/4eca2efd615f8abd65f576721e2410b19f0d40d0/data/data/manifests/bootkube/cvo-overrides.yaml.template#L8 [2]: https://github.com/openshift/cluster-version-operator/blob/fa452c2d270f1f989f3868ef97ae8cf825713583/docs/user/status.md#nochannel [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1827378#c4 [4]: openshift/cluster-version-operator#357 [5]: openshift/origin#24786 [6]: openshift/release#8631 Co-authored-by: W. Trevor King <wking@tremily.us> Co-authored-by: W. Trevor King <wking@tremily.us>
This was referenced Jul 20, 2023
petr-muller
added a commit
to petr-muller/release
that referenced
this pull request
Jul 21, 2023
…sible This PR is a part of the same effort as openshift#40703 and implements the same change as openshift#40711. This change is a separate step to avoid mixing up rehearsals. OTA maintains staging (identical to production) and integration (running on engineering candidate OCP clusters) Cincinnati instances. We are searching for traffic that we could route to especially the integration one, so that we can find possible problems with engineering candidate early. All the instances are serving identical data (up to some minimal skew coming from when individual instance scrape their source data) so we should be able to easily use the integration instance in CI clusters that are running a released OCP version. Most CI clusters are not running such versions, and these need to not query OSUS, otherwise they would trip an alert, causing noise in CI jobs. CI clusters are not querying OSUS since openshift#8631 We can enhance the logic to validate whether the version we are going to install is known to OSUS. If it is, we know we are installing a published OCP version and it is safe to let the cluster query OSUS. We still clear the channel to prevent the cluster from querying OSUS if we the version we install is not known to OSUS.
petr-muller
added a commit
to petr-muller/release
that referenced
this pull request
Aug 10, 2023
This PR is a part of the same effort as openshift#40703 OTA maintains staging (identical to production) and integration (running on engineering candidate OCP clusters) Cincinnati instances. We are searching for traffic that we could route to especially the integration one, so that we can find possible problems with engineering candidate early. All the instances are serving identical data (up to some minimal skew coming from when individual instance scrape their source data) so we should be able to easily use the integration instance in CI clusters that are running a released OCP version. Most CI clusters are not running such versions, and these must *not* query OSUS, otherwise they would trip an alert, causing noise in CI jobs. CI clusters are not querying OSUS since openshift#8631 We can enhance the logic to validate whether the version we are going to install is known to OSUS. If it is, we know we are installing a published OCP version and it is safe to let the cluster query OSUS. We still clear the channel to prevent the cluster from querying OSUS if we the version we install is not known to OSUS, or if this job involves upgrading the cluster to another version.
openshift-merge-robot
pushed a commit
that referenced
this pull request
Aug 10, 2023
#40711) This PR is a part of the same effort as #40703 OTA maintains staging (identical to production) and integration (running on engineering candidate OCP clusters) Cincinnati instances. We are searching for traffic that we could route to especially the integration one, so that we can find possible problems with engineering candidate early. All the instances are serving identical data (up to some minimal skew coming from when individual instance scrape their source data) so we should be able to easily use the integration instance in CI clusters that are running a released OCP version. Most CI clusters are not running such versions, and these must *not* query OSUS, otherwise they would trip an alert, causing noise in CI jobs. CI clusters are not querying OSUS since #8631 We can enhance the logic to validate whether the version we are going to install is known to OSUS. If it is, we know we are installing a published OCP version and it is safe to let the cluster query OSUS. We still clear the channel to prevent the cluster from querying OSUS if we the version we install is not known to OSUS, or if this job involves upgrading the cluster to another version.
petr-muller
added a commit
to petr-muller/release
that referenced
this pull request
Aug 14, 2023
…s, where possible This PR is a part of the same effort as openshift#40703 and implements the same change as openshift#40711. This change is a separate step to avoid mixing up rehearsals. OTA maintains staging (identical to production) and integration (running on engineering candidate OCP clusters) Cincinnati instances. We are searching for traffic that we could route to especially the integration one, so that we can find possible problems with engineering candidate early. All the instances are serving identical data (up to some minimal skew coming from when individual instance scrape their source data) so we should be able to easily use the integration instance in CI clusters that are running a released OCP version. Most CI clusters are not running such versions, and these need to not query OSUS, otherwise they would trip an alert, causing noise in CI jobs. CI clusters are not querying OSUS since openshift#8631 We can enhance the logic to validate whether the version we are going to install is known to OSUS. If it is, we know we are installing a published OCP version and it is safe to let the cluster query OSUS. We still clear the channel to prevent the cluster from querying OSUS if we the version we install is not known to OSUS.
petr-muller
added a commit
to petr-muller/release
that referenced
this pull request
Aug 17, 2023
…sible This PR is a part of the same effort as openshift#40703 and implements the same change as openshift#40711. This change is a separate step to avoid mixing up rehearsals. OTA maintains staging (identical to production) and integration (running on engineering candidate OCP clusters) Cincinnati instances. We are searching for traffic that we could route to especially the integration one, so that we can find possible problems with engineering candidate early. All the instances are serving identical data (up to some minimal skew coming from when individual instance scrape their source data) so we should be able to easily use the integration instance in CI clusters that are running a released OCP version. Most CI clusters are not running such versions, and these need to not query OSUS, otherwise they would trip an alert, causing noise in CI jobs. CI clusters are not querying OSUS since openshift#8631 We can enhance the logic to validate whether the version we are going to install is known to OSUS. If it is, we know we are installing a published OCP version and it is safe to let the cluster query OSUS. We still clear the channel to prevent the cluster from querying OSUS if we the version we install is not known to OSUS.
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.
CI and nightly releases are not part of the official Red Hat Cincinnati graphs. This commit removes the
channelproperty, which will result in theNoChannelcondition, but will keep the CVO from attempting to find its current version in the official Cincinnati (details). That in turn should keep the CVO from throwing a new, critical alert, which will keep it from running afoul of recent update e2e logic that forbids critical alerts.