Remove option to disable OSM

[ahmedwaleedmalik]

What this PR does / why we need it:
The user-data plugins from the machine-controller have been removed. OSM is mandatory now to create a functional cluster since we can't fall back on user data generated by the machine-controller anymore.

Which issue(s) this PR fixes:

Fixes #

What type of PR is this?

/kind cleanup

Special notes for your reviewer:
A follow-up PR for this will add guardrails in the installer to prevent upgrades if OSM has been explicitly disabled for a cluster. Users will have to update their clusters before the KKP upgrade. We can maybe add a flag to automate this as well but it's TBD.

Does this PR introduce a user-facing change? Then add your Release Note here:

Operating System Manager is now mandatory to create a functional cluster since machine-controller user-data plugins have been removed(https://github.com/kubermatic/machine-controller/pull/1789). Thus, the Operating System Manager is now always enabled for the user clusters.

Documentation:

NONE

[ahmedwaleedmalik]

/kind api-change
/label needs-release-testing

[kubermatic-bot]

@ahmedwaleedmalik: The label(s) /label needs-release-testing cannot be applied. These labels are supported: blocked by backend, merge-type/merge, merge-type/rebase, needs details, service accounts, Epic, MVP, customer-request, design, feature, proposal, ready-to-challenge, redesign, sig/api, sig/app-management, sig/cluster-management, sig/community, sig/infra, sig/networking, sig/ui, sig/virtualization, sprint, team/marketing, team/ps, lifecycle/frozen, backport-needed, backport-complete, ee, test/require-vsphere, test/require-kubevirt, test/require-vmwareclouddirector, test/require-nutanix. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

In response to this:

/kind api-change
/label needs-release-testing

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.

[ahmedwaleedmalik]

/label needs-release-testing

[kubermatic-bot]

@ahmedwaleedmalik: The label(s) /label needs-release-testing cannot be applied. These labels are supported: blocked by backend, merge-type/merge, merge-type/rebase, needs details, service accounts, Epic, MVP, customer-request, design, feature, proposal, ready-to-challenge, redesign, sig/api, sig/app-management, sig/cluster-management, sig/community, sig/infra, sig/networking, sig/ui, sig/virtualization, sprint, team/marketing, team/ps, lifecycle/frozen, backport-needed, backport-complete, ee, test/require-vsphere, test/require-kubevirt, test/require-vmwareclouddirector, test/require-nutanix. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?

In response to this:

/label needs-release-testing

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.

[ahmedwaleedmalik]

/label needs-release-testing

[ahmedwaleedmalik]

/retest

[ahmedwaleedmalik]

/retest

[ahmedwaleedmalik]

/assign @xrstf

[embik]

I had a similar deprecation/removal in #13316, so here's a question I had to ask myself: Is KKP going to be capable of differentiating between "this *bool field is unset because the cluster is old and still using MC user-data" and "this *bool is unset because the cluster is new and uses OSM by default"? Is there any migration code required that KKP will fail to run when it's confused about which type of cluster it is processing?

Maybe it makes sense to talk about this in SIG Cluster Management so we have a consistent way forward to deprecating fields in this release. As it stands, my PR will default the deprecated field to true, while this PR will go the opposite direction, and I think it would be nice if we adjusted behaviour.

[ahmedwaleedmalik]

Is KKP going to be capable of differentiating between "this *bool field is unset because the cluster is old and still using MC user-data" and "this *bool is unset because the cluster is new and uses OSM by default"? Is there any migration code required that KKP will fail to run when it's confused about which type of cluster it is processing?

Yeah, it should. As explained in the "reviewer notes," we'll have pre-flight checks in the installer to block users who have not enabled OSM. Migration, not sure, if we'll build it in the installer or just leave it up to the user.

[embik]

Gotcha, I misunderstood the reviewer notes for some reason saying we will only reject if the field is set to false explicitly. Makes sense though. For Konnectivity, I've opted for just rejecting upgrades when a cluster hasn't been migrated yet, so that operators can run upgrades in their own time (and not experience a force-upgrade/migration when installing the latest KKP).

[embik]

/approve

[kubermatic-bot]

LGTM label has been added.

Git tree hash: eb6eef185c1293efeb32bb56a0c01b8f698e83a4

[kubermatic-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: embik

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 [embik]
• hack/ci/OWNERS [embik]
• pkg/apis/OWNERS [embik]
• pkg/controller/OWNERS [embik]
• pkg/install/OWNERS [embik]
• pkg/resources/OWNERS [embik]

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