⚠️ Graduate MachinePools feature from experimental to stable API

[mboersma]

What this PR does / why we need it:

Moves MachinePools out of exp into api, and updates the numerous things that affects.

Which issue(s) this PR fixes:
Fixes #9005

/area api
/area machinepool

[k8s-ci-robot]

[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 enxebre for approval. For more information see the Kubernetes Code Review Process.

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

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

[mboersma]

This is still failing a unit test and possibly the e2e ClusterClass / MPs test. I'm working on it but thought it could benefit from the community's wisdom at this point.

Questions:

• Should we leave empty packages around in exp with just a doc.go file for future experimental features, or clean them up?
• Should we remove the EXP_MACHINEPOOL var and feature flag entirely now?
• Are we ready for this? (Are there other changes we may want before MachinePools are stable?)

[mboersma]

/retitle [WIP] ⚠️ Graduate MachinePools feature from experimental to stable API

[mboersma]

/test ?

[k8s-ci-robot]

@mboersma: The following commands are available to trigger required jobs:

• /test pull-cluster-api-build-main
• /test pull-cluster-api-e2e-blocking-main
• /test pull-cluster-api-e2e-conformance-ci-latest-main
• /test pull-cluster-api-e2e-conformance-main
• /test pull-cluster-api-e2e-main
• /test pull-cluster-api-e2e-mink8s-main
• /test pull-cluster-api-e2e-upgrade-1-30-1-31-main
• /test pull-cluster-api-test-main
• /test pull-cluster-api-test-mink8s-main
• /test pull-cluster-api-verify-main

The following commands are available to trigger optional jobs:

• /test pull-cluster-api-apidiff-main

Use /test all to run the following jobs that were automatically triggered:

• pull-cluster-api-apidiff-main
• pull-cluster-api-build-main
• pull-cluster-api-e2e-blocking-main
• pull-cluster-api-test-main
• pull-cluster-api-verify-main

In response to this:

/test ?

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.

[mboersma]

/retitle ⚠️ Graduate MachinePools feature from experimental to stable API

[sbueringer]

/test pull-cluster-api-e2e-conformance-ci-latest-main
/test pull-cluster-api-e2e-conformance-main
/test pull-cluster-api-e2e-main
/test pull-cluster-api-e2e-mink8s-main
/test pull-cluster-api-e2e-upgrade-1-30-1-31-main

[enxebre]

Thanks for this! I might have missed it but I don't see any docs updated on the PR which I assume we need.
Also it'd be good to share some insight on where we are on unit/test coverage for this feature #9005 (comment)

[k8s-ci-robot]

@mboersma: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-apidiff-main	3b64721	link	false	/test pull-cluster-api-apidiff-main

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

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.

[serngawy]

Can we break this PR to several PRs like first one with the stable API only , second with changing test and controllers.
Another thing is moving the API from exp to stable this will break any running environment "It will be tough for any environment to upgrade CAPI". I believe best approach to keep exp API with stable API, announce deprecation for at least 2 releases then remove it.

[k8s-ci-robot]

PR needs rebase.

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.

[mboersma]

Can we break this PR to several PRs

Of course we can, but I confess I'm not sure what changing the tests and controllers later would accomplish. Maybe I'm missing something.

When we discussed this at office hours, consensus seemed to be that this would be a breaking change, but only in terms of providers who import CAPI MachinePools code who need to change their imports. Specifically, expv1.MachinePool becomes clusterv1.MachinePool. Is there more to it than that?

I think you're suggesting maintaining both import paths for a couple releases, so there's a slower deprecation path. That seems reasonable, although I'd like to hear from other maintainers if they agree. Sorry if I'm misunderstanding something!

[serngawy]

Can we break this PR to several PRs

Of course we can, but I confess I'm not sure what changing the tests and controllers later would accomplish. Maybe I'm missing something.

When we discussed this at office hours, consensus seemed to be that this would be a breaking change, but only in terms of providers who import CAPI MachinePools code who need to change their imports. Specifically, expv1.MachinePool becomes clusterv1.MachinePool. Is there more to it than that?

I think you're suggesting maintaining both import paths for a couple releases, so there's a slower deprecation path. That seems reasonable, although I'd like to hear from other maintainers if they agree. Sorry if I'm misunderstanding something!

Thanks Matt for replying, As we discussed in the office hour the idea was be sure we are not breaking running env. So as we said changing the go path for the API package not changing the CRD definition. I guess we are safe to move the API, it will be breaking the imports in the providers source code only.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle rotten
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[fabriziopandini]

/close
As per discussion in recent office hours, we should regroup and step up maintaners in this area before re-considering this step (see #9005 (comment))

[k8s-ci-robot]

@fabriziopandini: Closed this PR.

In response to this:

/close
As per discussion in recent office hours, we should regroup and step up maintaners in this area before re-considering this step (see #9005 (comment))

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.