Cluster-api: UMBRELLA: Versioning and Support

[timothysc]

Describe the solution you'd like
Document where folks can find specific providers implementations.
When we cut v1alpha1 the first questions are going to be "what is supported", and "where do I find them?

On a separate note it would be ideal if this was somehow automated via some publishing mechanism.

/kind feature
/kind documentation

[timothysc]

/assign @ncdc

[vincepri]

/cc

[frapposelli]

/cc @frapposelli @sflxn

this is of interest for CAPV as well

[timothysc]

/assign @chuckha

[timothysc]

Here is a broad-strokes overview of the expectation here:

problem statement -> requirements -> options -> recommendations -> plan = KEP-ish

[vincepri]

Adding a plan of action for next steps:

• [ ] Proposal in google doc form with problem statement, objective and implementation (solution) details
• [ ] Discuss the proposal in the next community meeting
• [ ] Implement release process documenting required steps in gitbook
• [ ] [bonus] Automating the release process (probably after v1alpha1)

[chuckha]

/lifecycle active

[chuckha]

Some ideas about versioning in this document. Must be a member of kubernetes-dev or sig-cluster-lifecycle google groups.

[neolit123]

cc

[neolit123]

added some comments, for me key points are:

• standardize/interface kubeadm as the default boostrapper, move such logic outside of providers, but allow them the flex. this is already quite fragmented.
• standardize the support matrix template for providers in documentation (MD templates) and machine consumable way per provider repo or in the CAPI repo.
• consider complex version schemas such as "provider-version-capi-version".

[chuckha]

• [x] [Document existing release process in cluster api](https://github.com/kubernetes-sigs/cluster-api/issues/764)
• [x] [Document existing release process in provider-aws](https://github.com/kubernetes-sigs/cluster-api-provider-aws/issues/592)
• [ ] [Document other provider release processes] (vsphere, gcp, azure (@justaugustus) and others?
• [ ] Figure out if it makes sense to share one registry for this project and all providers or if each provider needs its own registry. Potentially talk with #wg-k8s-infra

[ncdc]

@chuckha what are our "done" criteria for this issue - when can we close the issue?

[chuckha]

@ncdc The lowest bar for closing this would be to open an issue on each provider telling them to document the version of kubernetes that is supported by which version of the provider.

A support grid on the provider.

[ncdc]

If that's the required action, can we close this now and proceed to open 1 issue per provider?

[chuckha]

yes, that's fine.

I'd recommend a grid similar to the one found in client-go. It would also be good to document the version of cluster-api that the version of the provider depends on, but I suppose not entirely necessary

[ncdc]

I think it is necessary to document the cluster-api version, since a full deployment requires both the cluster-api controllers and the provider controllers, and they have to talk the same language.

[ncdc]

Ok, before we close this, perhaps let's discuss the grid(s). Would you want something like this?

||Cluster API 0.1|Cluster API 0.2|
|-|-|-|
|AWS Provider 0.1|✓||
|AWS Provider 0.2||✓|

||Kubernetes 1.11|Kubernetes 1.12|Kubernetes 1.13|Kubernetes 1.14|
|-|-|-|-|-|
|AWS Provider 0.1|✓|✓|✓|
|AWS Provider 0.2||✓|✓|✓|

[chuckha]

Too bad READMEs don't do 3 dimensional grids 😂

That looks great to me :) Thanks for putting that together!

[ncdc]

AWS: https://github.com/kubernetes-sigs/cluster-api-provider-aws/issues/628
Azure: https://github.com/kubernetes-sigs/cluster-api-provider-azure/issues/125
GCP: https://github.com/kubernetes-sigs/cluster-api-provider-gcp/issues/113
vSphere: https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/issues/222
DigitalOcean: https://github.com/kubernetes-sigs/cluster-api-provider-digitalocean/issues/129
OpenStack: https://github.com/kubernetes-sigs/cluster-api-provider-openstack/issues/251

[ncdc]

@chuckha I think I got all the ones in kubernetes-sigs. Should I do the others too (OpenShift, Baidu, Tencent Cloud)?

[chuckha]

I think that's fine. I'm not sure how people are starting cluster-api-provider repos these days, but wherever those instructions live we should add this chart to the getting-started guide. I'll open a separate issue for that.

Thanks a bunch @ncdc !

/close

[k8s-ci-robot]

@chuckha: Closing this issue.

In response to this:

I think that's fine. I'm not sure how people are starting cluster-api-provider repos these days, but wherever those instructions live we should add this chart to the getting-started guide. I'll open a separate issue for that.

Thanks a bunch @ncdc !

/close

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.

[detiber]

@chuckha The gitbook would probably be the best place for that.