ipi-install-aws: use integration cincinnati in CI clusters, where possible #42290
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: petr-muller The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
/pj-rehearse |
|
/pj-rehearse periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-disconnected-sts-efs-p2-f14 periodic-ci-openshift-openshift-tests-private-release-4.12-arm64-nightly-4.12-upgrade-from-stable-4.11-aws-ipi-disconnected-private-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.13-amd64-nightly-4.13-upgrade-from-stable-4.13-aws-ipi-localzone-byo-subnet-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.13-arm64-stable-4.13-upgrade-from-stable-4.12-aws-ipi-disconnected-sts-ep-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.14-arm64-ec-aws-ipi-disconnected-sts-ep-f14 |
|
@petr-muller, |
|
/pj-rehearse periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-disconnected-sts-efs-p2-f14 periodic-ci-openshift-openshift-tests-private-release-4.12-arm64-nightly-4.12-upgrade-from-stable-4.11-aws-ipi-disconnected-private-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.13-amd64-nightly-4.13-upgrade-from-stable-4.13-aws-ipi-localzone-byo-subnet-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.13-arm64-stable-4.13-upgrade-from-stable-4.12-aws-ipi-disconnected-sts-ep-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.14-arm64-ec-aws-ipi-disconnected-sts-ep-f14 |
|
@petr-muller, |
…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
force-pushed
the
use-integration-cincinnati-ipi-install-install-aws
branch
from
41de26a to
9d01327
Compare
|
/pj-rehearse periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-disconnected-sts-efs-p2-f14 periodic-ci-openshift-openshift-tests-private-release-4.12-arm64-nightly-4.12-upgrade-from-stable-4.11-aws-ipi-disconnected-private-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.13-amd64-nightly-4.13-upgrade-from-stable-4.13-aws-ipi-localzone-byo-subnet-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.13-arm64-stable-4.13-upgrade-from-stable-4.12-aws-ipi-disconnected-sts-ep-p2-f28 periodic-ci-openshift-openshift-tests-private-release-4.14-arm64-ec-aws-ipi-disconnected-sts-ep-f14 |
|
[REHEARSALNOTIFIER]
A total of 318 jobs have been affected by this change. The above listing is non-exhaustive and limited to 35 jobs. A full list of affected jobs can be found here Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
@petr-muller: job(s): periodic-ci-openshift-openshift-tests-private-release-4.12-amd64-nightly-aws-ipi-disconnected-sts-efs-p2-f14, periodic-ci-openshift-openshift-tests-private-release-4.12-arm64-nightly-4.12-upgrade-from-stable-4.11-aws-ipi-disconnected-private-p2-f28 either don't exist or were not found to be affected, and cannot be rehearsed |
|
@petr-muller: The following tests failed, say
Full PR test history. Your PR dashboard. 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. |
|
Issues in openshift/release go stale after 30d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci
bot
added
the
lifecycle/stale
|
/close |
|
@petr-muller: Closed this PR. 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. |
petr-muller
deleted the
use-integration-cincinnati-ipi-install-install-aws
branch
3 participants
This PR is a part of the same effort as #40703 and implements the same change as #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 #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.