OTA-905: cincinnati client: query integration & staging instances

[petr-muller]

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 first, then the staging one, and if needed, use the production one as a backstop.

After:

$ ci-operator --org stackrox --repo stackrox --branch master --target=[images] --git-ref=stackrox/stackrox@master
...
INFO[2023-06-26T16:11:20+02:00] Requesting 4.12 from https://api.integration.openshift.com/api/upgrades_info/v1/graph?arch=amd64&channel=fast-4.12 
INFO[2023-06-26T16:11:21+02:00] Resolved release latest to quay.io/openshift-release-dev/ocp-release@sha256:ba7956f5c2aae61c8ff3ab1ab2ee7e625db9b1c8964a65339764db79c148e4e6

Before:

$ ci-operator --org stackrox --repo stackrox --branch master --target=[images] --git-ref=stackrox/stackrox@master
...
INFO[2023-06-26T16:14:56+02:00] Requesting 4.12 from https://api.openshift.com/api/upgrades_info/v1/graph?arch=amd64&channel=fast-4.12 
INFO[2023-06-26T16:14:57+02:00] Resolved release latest to quay.io/openshift-release-dev/ocp-release@sha256:ba7956f5c2aae61c8ff3ab1ab2ee7e625db9b1c8964a65339764db79c148e4e6

We can see that the release was resolved to the same pullspec after querying both api.integration.openshift.com and api.openshift.com/api endpoints.

[openshift-ci-robot]

@petr-muller: This pull request references OTA-905 which is a valid jira issue.

Details

In response to this:

• cincinnati client: cleanup deprecated ioutil usage
• cincinnati client: query integration & staging instances

After:

$ ci-operator --org stackrox --repo stackrox --branch master --target=[images] --git-ref=stackrox/stackrox@master
...
INFO[2023-06-26T16:11:20+02:00] Requesting 4.12 from https://api.integration.openshift.com/api/upgrades_info/v1/graph?arch=amd64&channel=fast-4.12 
INFO[2023-06-26T16:11:21+02:00] Resolved release latest to quay.io/openshift-release-dev/ocp-release@sha256:ba7956f5c2aae61c8ff3ab1ab2ee7e625db9b1c8964a65339764db79c148e4e6

Before:

$ ci-operator --org stackrox --repo stackrox --branch master --target=[images] --git-ref=stackrox/stackrox@master
...
INFO[2023-06-26T16:14:56+02:00] Requesting 4.12 from https://api.openshift.com/api/upgrades_info/v1/graph?arch=amd64&channel=fast-4.12 
INFO[2023-06-26T16:14:57+02:00] Resolved release latest to quay.io/openshift-release-dev/ocp-release@sha256:ba7956f5c2aae61c8ff3ab1ab2ee7e625db9b1c8964a65339764db79c148e4e6

We can see that the release was resolved to the same pullspec after querying both api.integration.openshift.com and api.openshift.com/api endpoints.

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.

[openshift-ci-robot]

@petr-muller: This pull request references OTA-905 which is a valid jira issue.

Details

In response to this:

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 first, then the staging one, and if needed, use the production one as a backstop.

After:

$ ci-operator --org stackrox --repo stackrox --branch master --target=[images] --git-ref=stackrox/stackrox@master
...
INFO[2023-06-26T16:11:20+02:00] Requesting 4.12 from https://api.integration.openshift.com/api/upgrades_info/v1/graph?arch=amd64&channel=fast-4.12 
INFO[2023-06-26T16:11:21+02:00] Resolved release latest to quay.io/openshift-release-dev/ocp-release@sha256:ba7956f5c2aae61c8ff3ab1ab2ee7e625db9b1c8964a65339764db79c148e4e6

Before:

$ ci-operator --org stackrox --repo stackrox --branch master --target=[images] --git-ref=stackrox/stackrox@master
...
INFO[2023-06-26T16:14:56+02:00] Requesting 4.12 from https://api.openshift.com/api/upgrades_info/v1/graph?arch=amd64&channel=fast-4.12 
INFO[2023-06-26T16:14:57+02:00] Resolved release latest to quay.io/openshift-release-dev/ocp-release@sha256:ba7956f5c2aae61c8ff3ab1ab2ee7e625db9b1c8964a65339764db79c148e4e6

We can see that the release was resolved to the same pullspec after querying both api.integration.openshift.com and api.openshift.com/api endpoints.

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.

[openshift-ci]

@petr-muller: all tests passed!

Full PR test history. Your PR dashboard.

Details

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. I understand the commands that are listed here.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: hongkailiu, petr-muller

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 [hongkailiu]

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