Heterogeneous architecture clusters

[Prashanth684]

Introduces support for provisioning and upgrading heterogenous architecture clusters in phases

[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

[bparees]

first pass

there's also a fair bit of formatting and typo cleanup needed that i didn't explicilty scrub for

also in general "manifestlist" is written as one word, it's effectively a noun.

[bparees]

so:
initially, we'll expect the user to provide any additional args/config in the machineset config
middle-state, we'll explicitly configure those things based on the arch
final-state, we'll auto-configure them based on generalized analysis

?

[Prashanth684]

i still have to understand from Colin/Mrunal the changes involved here for MCO.

[Prashanth684]

@mrunalp could you please clarify what specifically would change in MCO when we support heterogeneous clusters a opposed to what we are doing today ?

[Prashanth684]

first pass

there's also a fair bit of formatting and typo cleanup needed that i didn't explicilty scrub for

also in general "manifestlist" is written as one word, it's effectively a noun.

did a fair bit of cleanup on the typos and formatting.

[deads2k]

is there going to be a metric exposing this so that we can slice our telemetry data based on this information?

[Prashanth684]

Yes in the future we do want to have this. Today for collecting data on the number of clusters per arch we have to look at a node's arch label. This will make it easier going forward to identify the cluster arch from the ClusterVersionStatus field rather than looking at a node's arch in that cluster.

[bparees]

i'm a little unclear on the intent of this EP at this point. Given 4.11 is about to ship, i'd expect this EP to be a lot more concrete about exactly what is/was done for 4.11/phase1, and then reserving the more "design" bits for the work that still needs to be done.

[Prashanth684]

i'm a little unclear on the intent of this EP at this point. Given 4.11 is about to ship, i'd expect this EP to be a lot more concrete about exactly what is/was done for 4.11/phase1, and then reserving the more "design" bits for the work that still needs to be done.

this enhancement was opened in January and since then there are a lot of changes and lot of implementation details that have been worked on and changed. that being said, the deliverables for 4.11 (and other phases) are reflected accurately i believe. I have tried to keep most of the component sections up to date, but i see that there are several sections which are outdated. It would be good to get this merged soon, so incremental changes can be made by the individual component teams themselves as they progress. In the meanwhile I will work on updating all sections to reflect the latest so we can get it merged by end of next week.

[Prashanth684]

i'm a little unclear on the intent of this EP at this point. Given 4.11 is about to ship, i'd expect this EP to be a lot more concrete about exactly what is/was done for 4.11/phase1, and then reserving the more "design" bits for the work that still needs to be done.

this enhancement was opened in January and since then there are a lot of changes and lot of implementation details that have been worked on and changed. that being said, the deliverables for 4.11 (and other phases) are reflected accurately i believe. I have tried to keep most of the component sections up to date, but i see that there are several sections which are outdated. It would be good to get this merged soon, so incremental changes can be made by the individual component teams themselves as they progress. In the meanwhile I will work on updating all sections to reflect the latest so we can get it merged by end of next week.

@bparees i've cleaned up some of the sections which did not reflect the current plan. Are there any other concerns from your side as i look to merge this week?

[bparees]

i've cleaned up some of the sections which did not reflect the current plan. Are there any other concerns from your side as i look to merge this week?

@Prashanth684 no further concerns, the cleanup has significantly improved readability and made it clearer what work is being proposed in what areas/components(and why). Thanks!

[enxebre]

which images is this referring this exactly? we infer everything else from hostedCluster.spec.release.image, so as far as that's heterogeneous, any component should pick the right arch from there.

[Prashanth684]

i'm referring to these: https://github.com/openshift/hypershift/tree/main/support/releaseinfo/fixtures . shouldn't there be a fixture added with manifestlisted pullspecs for heterogeneous?

[bparees]

/approve
/lgtm

i expect this EP will continue to be a living document as we work our way through the implementation phases, but for now it outlines the big picture steps we need to take and the implications.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bparees

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

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

[openshift-ci]

@Prashanth684: all tests passed!

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.