[v1alpha2]: prepare for v1alpha2 adoption

[jichenjc]

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]

kubernetes-sigs/cluster-api#997 introduced some design doc
about v1alpha2, we should start to think about how to enable it
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

[sbueringer]

I would start working on this
/assign @sbueringer

[jichenjc]

yes, let's joint work on this, I am studying and preparing for this as well
so maybe we can make sub-tasks :)

[sbueringer]

Yup okay. I need a few days to catch up to the current status of v1alpha2

[sbueringer]

It would be nice if we could get this done first: #382

I have all the code here. Just have to merge the APIServerLB PR and one final on to implement kubeadm.

If we move to v1alpha2 first I fear I have to reimplement a lot of that stuff.

[jichenjc]

we may need create another branch for v1alpha2 ?

[sbueringer]

Definitely. I'm just looking at AWS and I guess it will be more or less half rewrite and the other half copy&pase of existing OpenStack-specific code. That's why it would be nice to have the kubeadm change on master before start copying it on the v1alpha2 branch to avoid a lot of sync effort.

[texascloud]

I'm interested in helping out with this effort. LMK how I can help

[texascloud]

kubernetes-sigs/cluster-api-provider-aws#933 here's an issue with some guidance we could extrapolate from

[texascloud]

Consider either tagging this issue, or adding a [v1alpha2] prefix to the issue title so it may be more easily tracked, thanks!

[sbueringer]

I'm interested in helping out with this effort. LMK how I can help

That's nice to here, thx!

I'm not really sure how we should do the migration to v1alpha2. I think we should do it in the following order:

• Pre-Migration:

  • migrate to go.mod
  • Finalize Support for multi-node control plane #382

• Migration:

  • Migrate Machine Actuator/Controller, similar to: CAPA v1alpha2 🎉 cluster-api-provider-aws#892
  • Migrate Cluster Actuator/Controller: [v1alpha2] Implement AWSCluster controller cluster-api-provider-aws#933

In my opinion we should finalize the HA control plane feature before, because it's really big and to combine this with a really complex refactoring to v1alpha2 makes it far more complicated.

Regarding the migration to v1alpha2 itself. If you look at the first PR in CAPA (892). It's a really huge & complicated refactoring. We probably should do both refactorings on another branch and "freeze" development of major features no master in the meantime to reduce the sync effort between both branches.

I'm not sure how we can split these two big refactorings in smaller subtasks. What do you think?

[texascloud]

If I get some time this week I'll look at how to break them down into smaller subtasks. 892 PR is so big it actually crashed my chrome tab lol. Lots of repo cleanup happening in that PR. I believe there is a different way to structure the repo based on kubebuilder best practices. Not sure if that should be done as part of the refactor. But if it isn't done as part of this refactor, I feel it's less likely to happen in the future.

Regarding Generate kubeadm configs for multi-node control plane on #382, I think that is complicated. In v1alpha2 we have a kubeadm Bootstrap provider being started, which should ideally handle all multi control plane cluster configuration. So the last point on #382 would be a stop-gap solution for v1alpha1 IMO