OCPBUGS-13547: Use payload-version flag to set release version consistently across components

[JoelSpeed]

- What I did

Adds a --payload-version flag to all the components in this repo (MCC, MCS, MCO, MCD) so that they consistently populate the release version into version.ReleaseVersion. The payload version is already used in MCO in a couple of places via env vars, so this includes a backwards compatible env var pre-population, but the intention is to remove that shortly (once the installer populates the flag for the bootstrap) and then the only, and consistent way to set the release version within the MCO suite would be via the flag. In code/tests it can be set via setting version.ReleaseVersion.

This should make the usage consistent across the codebase ahead of introducing feature gate changes on top of this.

- How to verify it

Should be no functional changes, will want to check the various manifests are generated with the correct versions.

- Description for the changelog

Use consistent payload-version flag to load release version information.

N.B: 0.0.1-snapshot is a magic string that is replaced during the payload build process, so the install manifests for MCO should get the correct version when the payload is built.

[JoelSpeed]

Test failures are kinda weird, and looking at some other jobs, I'm wondering if there's a race here.
The machine-config-daemon render seems to rely on the machine-config-controller render, but the machine-config-controller render comes after the machine-config-daemon render. So because the MCD render failed (daemonset degraded because they can't find the rendered MC), this prevents us from ever creating the rendered MC.

Does anyone know why they are that way around?

Going to retest to get more data

/retest

[JoelSpeed]

I've successfully installed a cluster from this PR this morning, after some teething trouble, I think this is good to go.
The PR should be inert in terms of feature changes, since it's only adding a flag that is defaulting to the existing method, looking up via env var.

[sinnykumari]

LGTM

[openshift-ci]

@JoelSpeed: 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-e2e-gcp-ovn-upgrade	131bf03	link	false	/test okd-scos-e2e-gcp-ovn-upgrade
ci/prow/e2e-alibabacloud-ovn	131bf03	link	false	/test e2e-alibabacloud-ovn

Full PR test history. Your PR dashboard.

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

@JoelSpeed: This pull request references Jira Issue OCPBUGS-13547, which is valid.

3 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.14.0) matches configured target version for branch (4.14.0)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @sunzhaohua2

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

- What I did

Adds a --payload-version flag to all the components in this repo (MCC, MCS, MCO, MCD) so that they consistently populate the release version into version.ReleaseVersion. The payload version is already used in MCO in a couple of places via env vars, so this includes a backwards compatible env var pre-population, but the intention is to remove that shortly (once the installer populates the flag for the bootstrap) and then the only, and consistent way to set the release version within the MCO suite would be via the flag. In code/tests it can be set via setting version.ReleaseVersion.

This should make the usage consistent across the codebase ahead of introducing feature gate changes on top of this.

- How to verify it

Should be no functional changes, will want to check the various manifests are generated with the correct versions.

- Description for the changelog

Use consistent payload-version flag to load release version information.

N.B: 0.0.1-snapshot is a magic string that is replaced during the payload build process, so the install manifests for MCO should get the correct version when the payload is built.

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.

[yuqi-zhang]

/lgtm

Thanks Joel!

/hold

For qe verification. Although I think this might be ok as-is since the env var overrides the new flag, so feel free to unhold if we feel that isn't needed

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed, sinnykumari, yuqi-zhang

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [sinnykumari,yuqi-zhang]

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

[JoelSpeed]

For qe verification. Although I think this might be ok as-is since the env var overrides the new flag, so feel free to unhold if we feel that isn't needed

I'm going to skip on this as this change should be inert, as you say, the change is still using the old env var for now and the rest of the changes are all contained in adding a new flag, which shouldn't need any additional validation other than x thing runs, which E2E has proven.

Will make sure E2E check on MCO when we do the end to end test with the installer bit as well and 3688

/hold cancel

[openshift-ci-robot]

@JoelSpeed: Jira Issue OCPBUGS-13547: Some pull requests linked via external trackers have merged:

The following pull requests linked via external trackers have not merged:

• openshift/cluster-cloud-controller-manager-operator#249 is open

These pull request must merge or be unlinked from the Jira bug in order for it to move to the next state. Once unlinked, request a bug refresh with /jira refresh.

Jira Issue OCPBUGS-13547 has not been moved to the MODIFIED state.

In response to this:

- What I did

Adds a --payload-version flag to all the components in this repo (MCC, MCS, MCO, MCD) so that they consistently populate the release version into version.ReleaseVersion. The payload version is already used in MCO in a couple of places via env vars, so this includes a backwards compatible env var pre-population, but the intention is to remove that shortly (once the installer populates the flag for the bootstrap) and then the only, and consistent way to set the release version within the MCO suite would be via the flag. In code/tests it can be set via setting version.ReleaseVersion.

This should make the usage consistent across the codebase ahead of introducing feature gate changes on top of this.

- How to verify it

Should be no functional changes, will want to check the various manifests are generated with the correct versions.

- Description for the changelog

Use consistent payload-version flag to load release version information.

N.B: 0.0.1-snapshot is a magic string that is replaced during the payload build process, so the install manifests for MCO should get the correct version when the payload is built.

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.