MCO-501: Infer OS version from image labels

[cheesesashimi]

- What I did

• I've added code that can infer what version the new OS is from the image labels. This could be useful in future cases where we might need to perform some type of pre-work before applying a new OS image.
• Like with the node OS detection code, I've wired it into an e2e test so that we are constantly testing this code path.
• I've also modified the MCD to use an interface for OS detection, allowing us to substitute a fake OS implementation for testing. This will allow us to easily reach OS-dependent code-paths without much overhead.

NOTE: Except for the e2e test, this code does not actually query the image registry which contains the new node OS container. It only parses the results from it.

- How to verify it

• Run the unit tests to verify that the new label inference code works correctly.
• Run the e2e tests and verify that a line resembling: node_os_test.go:38: Found OS image "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:329a8968765c2eca37d8cbd95ecab0400b5252a680eea9d279f41d7a8b4fdb93" matching tag "rhel-coreos-8" in OCP / OKD release image "registry.ci.openshift.org/ocp/release@sha256:21a7209435eb0461c1a931e0245b9e77ea7fe9ae266acca90e53b93cb2dbc4ea". Will compare to what is on cluster nodes is contained therein.

- Description for the changelog
Enables inferring what the next node OS will be before upgrading

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cheesesashimi

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

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

[cheesesashimi]

/test unit
/test verify

[openshift-ci-robot]

@cheesesashimi: This pull request references MCO-501 which is a valid jira issue.

Details

In response to this:

- What I did

• I've added code that can infer what version the new OS is from the image labels. This could be useful in future cases where we might need to perform some type of pre-work before applying a new OS image.
• Like with the node OS detection code, I've wired it into an e2e test so that we are constantly testing this code path.
• I've also modified the MCD to use an interface for OS detection, allowing us to substitute a fake OS implementation for testing. This will allow us to easily reach OS-dependent code-paths without much overhead.

NOTE: Except for the e2e test, this code does not actually query the image registry which contains the new node OS container. It only parses the results from it.

- How to verify it

• Run the unit tests to verify that the new label inference code works correctly.
• Run the e2e tests and verify that a line resembling: node_os_test.go:38: Found OS image "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:329a8968765c2eca37d8cbd95ecab0400b5252a680eea9d279f41d7a8b4fdb93" matching tag "rhel-coreos-8" in OCP / OKD release image "registry.ci.openshift.org/ocp/release@sha256:21a7209435eb0461c1a931e0245b9e77ea7fe9ae266acca90e53b93cb2dbc4ea". Will compare to what is on cluster nodes is contained therein.

- Description for the changelog
Enables inferring what the next node OS will be before upgrading

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.

[cheesesashimi]

/test unit
/test verify
/test e2e-gcp-op

[openshift-ci]

@cheesesashimi: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/okd-scos-images	c0d4135	link	true	/test okd-scos-images
ci/prow/okd-scos-e2e-aws-ovn	c0d4135	link	false	/test okd-scos-e2e-aws-ovn
ci/prow/e2e-gcp-op	c0d4135	link	true	/test e2e-gcp-op
ci/prow/okd-images	c0d4135	link	false	/test okd-images
ci/prow/verify	c0d4135	link	true	/test verify
ci/prow/images	c0d4135	link	true	/test images
ci/prow/e2e-aws-ovn-upgrade	c0d4135	link	true	/test e2e-aws-ovn-upgrade
ci/prow/e2e-alibabacloud-ovn	c0d4135	link	false	/test e2e-alibabacloud-ovn
ci/prow/unit	c0d4135	link	true	/test unit
ci/prow/okd-scos-e2e-gcp-ovn-upgrade	c0d4135	link	false	/test okd-scos-e2e-gcp-ovn-upgrade
ci/prow/e2e-aws-ovn	c0d4135	link	true	/test e2e-aws-ovn
ci/prow/e2e-hypershift	c0d4135	link	true	/test e2e-hypershift

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-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-ci-robot]

@cheesesashimi: This pull request references MCO-501 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.15.0" version, but no target version was set.

Details

In response to this:

- What I did

• I've added code that can infer what version the new OS is from the image labels. This could be useful in future cases where we might need to perform some type of pre-work before applying a new OS image.
• Like with the node OS detection code, I've wired it into an e2e test so that we are constantly testing this code path.
• I've also modified the MCD to use an interface for OS detection, allowing us to substitute a fake OS implementation for testing. This will allow us to easily reach OS-dependent code-paths without much overhead.

NOTE: Except for the e2e test, this code does not actually query the image registry which contains the new node OS container. It only parses the results from it.

- How to verify it

• Run the unit tests to verify that the new label inference code works correctly.
• Run the e2e tests and verify that a line resembling: node_os_test.go:38: Found OS image "quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:329a8968765c2eca37d8cbd95ecab0400b5252a680eea9d279f41d7a8b4fdb93" matching tag "rhel-coreos-8" in OCP / OKD release image "registry.ci.openshift.org/ocp/release@sha256:21a7209435eb0461c1a931e0245b9e77ea7fe9ae266acca90e53b93cb2dbc4ea". Will compare to what is on cluster nodes is contained therein.

- Description for the changelog
Enables inferring what the next node OS will be before upgrading

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-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci]

@openshift-bot: Closed this PR.

Details

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.