OTA-905: generic-claim: use integration cincinnati instance in hive clusters #40703
Conversation
openshift-ci
bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
/pj-rehearse |
openshift-ci
bot
added
the
approved
petr-muller
force-pushed
the
use-integration-cincinnati-in-hive-clusters
branch
from
96d5858 to
85925f8
Compare
|
/pj-rehearse |
|
/test all |
|
/pj-rehearse pull-ci-openshift-cincinnati-operator-master-operator-e2e-410 |
openshift-ci
bot
removed
the
approved
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.11-kuttl-sequential |
petr-muller
force-pushed
the
use-integration-cincinnati-in-hive-clusters
branch
from
92d9cd2 to
8a586c0
Compare
|
/test all |
petr-muller
force-pushed
the
use-integration-cincinnati-in-hive-clusters
branch
from
8a586c0 to
800795d
Compare
petr-muller
changed the title
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
/pj-rehearse pull-ci-openshift-cincinnati-master-e2e pull-ci-openshift-special-resource-operator-release-4.13-e2e-aws-ocp periodic-ci-openshift-knative-serverless-operator-main-4.13-upstream-e2e-kafka-aws-ocp-413-continuous pull-ci-openshift-knative-serverless-operator-main-4.13-ui-tests |
|
/retest |
|
/cc @openshift/test-platform @wking DPTP for ci-operator/step-registry/generic-claim and Trevor for ci-operator/step-registry/openshift |
openshift-ci
bot
requested review from
a team and
wking
and removed request for
deepsm007 and
neisw
petr-muller
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@petr-muller: This pull request references OTA-905 which is a valid jira issue. 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: This pull request references OTA-905 which is a valid jira issue. 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
force-pushed
the
use-integration-cincinnati-in-hive-clusters
branch
from
800795d to
a5e0b8d
Compare
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 (which all Hive clusters are). 1. Introduce a `configure-cincinnati` step that uses `oc` to set a cincinnati instance the cluster should use, and also to switch a channel to a desired one of the same version if a cluster is configured to follow a channel (otherwise we do not know what version to use). 2. Make `generic-claim` workflow to use this step to switch Hive-provisioned clusters to use integration OSUS instance and a candidate channel. This should not have any observable effect on jobs, it is just a mean to get more traffic to the integration OSUS instance.
petr-muller
force-pushed
the
use-integration-cincinnati-in-hive-clusters
branch
from
a5e0b8d to
5ce92dc
Compare
|
/pj-rehearse ack |
openshift-ci-robot
added
rehearsals-ack
|
[REHEARSALNOTIFIER]
A total of 483 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: |
|
/pj-rehearse ack |
openshift-ci-robot
added
the
rehearsals-ack
|
@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. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: petr-muller, smg247 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 |
openshift-ci
bot
added
the
approved
…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.
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.
#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.
…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.
…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.
5 participants
This PR is a part of the same effort like openshift/ci-tools#3512
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 (which all Hive clusters are).
configure-cincinnatistep that usesocto set a cincinnati instance the cluster should use, and also to switch a channel to a desired one of the same version if a cluster is configured to follow a channel (otherwise we do not know what version to use).generic-claimworkflow to use this step to switch Hive-provisioned clusters to use integration OSUS instance anda candidate channel.
This should not have any observable effect on jobs, it is just a mean to get more traffic to the integration OSUS instance.