OCPEDGE-1313: feat: added assets for arbiter node role

[eggfoobar]

- What I did

Added initial support for the arbiter node role. The arbiter role currently mimics the master node in configuration, so we are copying the same assets for master and using it for arbiter.

This feature is currently for TechPreview but before we hit GA we will re-work this approach to remove duplication.

See: openshift/enhancements#1674

- How to verify it

This feature will only work on baremetal HighlyAvailableArbiter control plane topology clusters. When running on those deployments, an MCP for arbiter and MCs for arbiter deployments should be present. Otherwise no trace of Arbiter should be present in the generated configs.

- Description for the changelog

[openshift-ci-robot]

@eggfoobar: This pull request references OCPEDGE-1313 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.18.0" version, but no target version was set.

In response to this:

- What I did

- How to verify it

- Description for the changelog

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@eggfoobar: This pull request references OCPEDGE-1313 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.19.0" version, but no target version was set.

In response to this:

- What I did

Added initial support for the arbiter node role. The arbiter role currently mimics the master node in configuration, so we are copying the same assets for master and using it for arbiter. This feature is currently designed for TechPreview but before we hit GA we will re-work this approach to remove duplication.

See: openshift/enhancements#1674

- How to verify it

This feature will only work on baremetal HighlyAvailableArbiter control plane topology clusters. When running on those deployments, an MCP for arbiter and MCs for arbiter deployments should be present. Otherwise no trace of Arbiter should be present in the generated configs.

- Description for the changelog

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@eggfoobar: This pull request references OCPEDGE-1313 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.19.0" version, but no target version was set.

In response to this:

- What I did

Added initial support for the arbiter node role. The arbiter role currently mimics the master node in configuration, so we are copying the same assets for master and using it for arbiter.

This feature is currently for TechPreview but before we hit GA we will re-work this approach to remove duplication.

See: openshift/enhancements#1674

- How to verify it

This feature will only work on baremetal HighlyAvailableArbiter control plane topology clusters. When running on those deployments, an MCP for arbiter and MCs for arbiter deployments should be present. Otherwise no trace of Arbiter should be present in the generated configs.

- Description for the changelog

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 openshift-eng/jira-lifecycle-plugin repository.

[eggfoobar]

/retest-required

[yuqi-zhang]

Generally looks good to me, the main concern of don't-have-arbiter-artifacts-by-default is addressed. A few (non-blocking) questions/concerns:

1. will this feature not undergo tech preview? Will you need to add MCO presubmits for arbiter-related CI?
2. we don't really have anything monitoring templates, as such if we were to say, add additional master file/unit templates in the future, is the expectation that they should also be added to arbiter? Should we have some mechanism to check for that?

[eggfoobar]

Generally looks good to me, the main concern of don't-have-arbiter-artifacts-by-default is addressed. A few (non-blocking) questions/concerns:

1. will this feature not undergo tech preview? Will you need to add MCO presubmits for arbiter-related CI?
2. we don't really have anything monitoring templates, as such if we were to say, add additional master file/unit templates in the future, is the expectation that they should also be added to arbiter? Should we have some mechanism to check for that?

1. This feature will be in TechPreview for 4.19, the infra resource will never be set to the HighlyAvailableArbiter unless the install is in TechPreview. This should be enforced by the API since the GA infra CRD does not support HighlyAvailableArbiter value unless TechPreview featureSet is enabled. We will be having arbiter CI, more than likely if we create presubmits they will be optional until GA, but we'll also have origin tests that validate behavior.
2. That's a great call out, and something that will be resolved prior to going to GA. I don't have a great answer for now since we don't have solid knowledge on the types of machines customers will use, so I'm reluctant to pre-optimize just yet. Some things to keep in mind as well, this feature is currently only for baremetal installs. You're right that we'll have a need to check for diffs between the two for awareness, whether we should copy all configs added to master for the arbiter folder, that will depend on the config and what we catch in our CI to help inform us for now.

[yuqi-zhang]

/lgtm

I'm not too familiar with the tech preview process, but since all the code here is gated behind HighlyAvailableArbiter and that's gated behind a FG, I think it should be fine not to explicitly gate the MCO code here too.

This shouldn't break existing CI either so I'm fine with getting this in so we can start adding tests

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: eggfoobar, 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 [yuqi-zhang]

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

[openshift-ci]

@eggfoobar: 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-aws-ovn	2d4bca0	link	false	/test okd-scos-e2e-aws-ovn
ci/prow/e2e-aws-ovn-upgrade-out-of-change	2d4bca0	link	false	/test e2e-aws-ovn-upgrade-out-of-change
ci/prow/e2e-vsphere-ovn-upi	2d4bca0	link	false	/test e2e-vsphere-ovn-upi
ci/prow/e2e-azure-ovn-upgrade-out-of-change	2d4bca0	link	false	/test e2e-azure-ovn-upgrade-out-of-change
ci/prow/e2e-gcp-op-ocl	2d4bca0	link	false	/test e2e-gcp-op-ocl

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

[eggfoobar]

/label acknowledge-critical-fixes-only

[openshift-bot]

[ART PR BUILD NOTIFIER]

Distgit: ose-machine-config-operator
This PR has been included in build ose-machine-config-operator-container-v4.19.0-202501210838.p0.g0082265.assembly.stream.el9.
All builds following this will include this PR.