Consider moving MachinePool to experimental

[juan-lee]

User Story

As a developer I would like to be able to freely evolve the MachinePool API after v1alpha3 is released due to new requirements around AWS/Azure SPOT support.

Detailed Description

Does it make sense for MachinePool to be in an experimental category for some amount of time before being included in the core api? Features like SPOT for AWS and Azure might require some evolution of the MachinePool API. Once we release v1alpha3, API deprecation policies might make it difficult to accommodate change.

/kind feature

[juan-lee]

@vincepri FYI

[ncdc]

SGTM, thanks for proposing this.

[vincepri]

+1 to this change, I think it makes a lot of sense given the nature of these new API types. Let's chat about it at the next community meeting? I'll play around with it and open a PR to move the types, we can then review/merge next week if there is enough consensus.

/milestone v0.3.0-rc.3
/assign

cc @JoelSpeed, if we want to do the same for MHC?

[JoelSpeed]

With regards to MHC, I'm not opposed to the idea of moving to an experimental group if that allows the main CRDs within the group to be promoted to beta and eventually GA. This decision, IMO, should be deferred to people with more experience in the project than I have.

That said, I would like to add some context to help the decision. I think the MHC project is a lot smaller than the MachinePool project and is likely to have fewer changes needed to it than MachinePool is likely to need. We introduced MHC into Openshift back in Openshift 4.1 (K8s 1.13) so it has already had some time to mature in our implementation before being ported over to CAPI. In terms of the API of the MHC, I can't think of anything off the top of my head that will need changing in the mid term, the only problems I'm aware of right now (with the current implementation plans at least) are that MHC doesn't currently support MachinePool (could this need an API change?) and there could be an argument for adding backoff/ratelimiting to MHC. I suspect both of these changes would largely be internal and not API breaking.

@enxebre do you have anything to add on this topic?

[enxebre]

Just one note, we introduced MHC as tech preview in 4.1 and GA in 4.3.

Regarding the experimental category for MHC I'm not opposed to that but I agree with @JoelSpeed I wouldn't anticipate any breaking API changes on MHC. The heavy implementation development is already done, plus we are alpha. I'd see this a more suitable case for MHC if we were in an already beta API scenario.

MHC doesn't currently support MachinePool

I wouldn't expect this to happen as machinePool by design relies on the native provider implementation for managing/scaling/health-checking a pool of instances.

Regarding machines/machineSets, MachinePool and spot instances I would expect incremental changes to happen at the provider API level.

[vincepri]

/close

Closing now that the PR has been merged

[k8s-ci-robot]

@vincepri: Closing this issue.

In response to this:

/close

Closing now that the PR has been merged

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.