OCPBUGS-64793: use master schedulability for topology calculation

[patrickdillon]

When masters are schedulable OLM and ingress operator (and anything else) can schedule infrastructure to the control plane. So the infrastructure topology needs to take master schedulability into account.

Example of local testing:

[root@25ba1b58bcdb /]# yq .spec.mastersSchedulable c/manifests/cluster-scheduler-02-config.yml
false
[root@25ba1b58bcdb /]# yq .status.infrastructureTopology c/manifests/cluster-infrastructure-02-config.yml
SingleReplica
[root@25ba1b58bcdb /]# vi c/manifests/cluster-scheduler-02-config.yml
[root@25ba1b58bcdb /]# yq .spec.mastersSchedulable c/manifests/cluster-scheduler-02-config.yml
true
[root@25ba1b58bcdb /]# ./openshift-install create manifests --dir c
WARNING Discarding the Common Manifests that was provided in the target directory because its dependencies are dirty and it needs to be regenerated
INFO Successfully populated MCS CA cert information: root-ca 2036-02-29T20:45:41Z 2026-03-03T20:45:41Z
INFO Successfully populated MCS TLS cert information: root-ca 2036-02-29T20:45:41Z 2026-03-03T20:45:41Z
INFO Consuming Scheduler Config from target directory
INFO Consuming OpenShift Install (Manifests) from target directory
INFO Manifests created in: c/cluster-api, c/manifests and c/openshift
[root@25ba1b58bcdb /]# yq .status.infrastructureTopology c/manifests/cluster-infrastructure-02-config.yml
HighlyAvailable

[openshift-ci-robot]

@patrickdillon: This pull request references Jira Issue OCPBUGS-64793, which is valid.

3 validation(s) were run on this bug

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

Requesting review from QA contact:
/cc @gpei

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

Details

In response to this:

When masters are schedulable OLM and ingress operator (and anything else) can schedule infrastructure to the control plane. So the infrastructure topology needs to take master schedulability into account.

Example of local testing:

[root@25ba1b58bcdb /]# yq .spec.mastersSchedulable c/manifests/cluster-scheduler-02-config.yml
false
[root@25ba1b58bcdb /]# yq .status.infrastructureTopology c/manifests/cluster-infrastructure-02-config.yml
SingleReplica
[root@25ba1b58bcdb /]# vi c/manifests/cluster-scheduler-02-config.yml
[root@25ba1b58bcdb /]# yq .spec.mastersSchedulable c/manifests/cluster-scheduler-02-config.yml
true
[root@25ba1b58bcdb /]# ./openshift-install create manifests --dir c
WARNING Discarding the Common Manifests that was provided in the target directory because its dependencies are dirty and it needs to be regenerated
INFO Successfully populated MCS CA cert information: root-ca 2036-02-29T20:45:41Z 2026-03-03T20:45:41Z
INFO Successfully populated MCS TLS cert information: root-ca 2036-02-29T20:45:41Z 2026-03-03T20:45:41Z
INFO Consuming Scheduler Config from target directory
INFO Consuming OpenShift Install (Manifests) from target directory
INFO Manifests created in: c/cluster-api, c/manifests and c/openshift
[root@25ba1b58bcdb /]# yq .status.infrastructureTopology c/manifests/cluster-infrastructure-02-config.yml
HighlyAvailable

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]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign bfournie for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[zaneb]

Are there any fields in the Infrastructure CR that are not derived from the install-config? The issue with cross-dependencies is as follows:

• The user does create manifests
• The user edits the mastersSchedulable field (or any other field) in the Scheduler CR
• The user edits some field (other than InfrastructureTopology) in the Infrastructure CR
• The user does create ignition-configs or create cluster

I believe in this case, the Infrastructure CR will be regenerated, resulting in the correct InfrastrucutreTopology but wiping out any other changes. But perhaps that's OK if there is nothing you would conceivably want to change in Infrastructure because everything is configurable in the install-config already.

[openshift-ci]

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

[patrickdillon]

I believe in this case, the Infrastructure CR will be regenerated

Yes, exactly & as you say the user changes to infrastructure will be lost. Also, note that in the log message it says "Common Manifests" so either best case scenario that is just an error in the log message but perhaps all manifests are being regenerated 😱 Will check that.

I would guess the infrastructure manifest is one of the most common manifests to be edited. For example, I could definitely imagine a UPI install editing these two.

/hold
for confirmation & discussion

Users could potentially avoid this problem by running create manifests after each manifest edit, but nobody is doing that.. theoretically we might be able to make them do it by throwing an error, but that doesn't seem, um, ideal

In terms of resolving the bug...

As we discussed, we could give users a way to avoid the problem with an install config field for mastersSchedulable. Perhaps we even backport it if a user is affected by the bug?

The only actual fix I see to the problem is a cluster controller

Actually, it just occurred to me we could potentialy (and probably should) use the cluster-config-operator during bootstrapping to set the value