Cluster-api: Out of date documentation for provider implementers

Created on 18 Aug 2020 · 7Comments · Source: kubernetes-sigs/cluster-api

What steps did you take and what happened:
In our documentation we have a list of providers. Here we track the ones that follow v1alpha3 types.

Providers marked in bold are known to support v1alpha3 API types.

However, the list seems to be incorrect because providers like OpenStack and Packet seem to follow the v1alpha3 contract but are not marked as bold.

What did you expect to happen:

Either we should not mark providers that are abiding by the v1alpha3 contract in bold since the list will eventually go out of date and become misleading.
OR
If we want to track what providers are supporting v1alpha3 contracts, we should update this list to ensure we aren't providing misleading information.

Anything else you would like to add:
Is there a way to automate this? With the next release of v1alpha4, should this become a table that's auto generated?

Environment:

Cluster-api version: <=v0.3.8
Minikube/KIND version: n/a
Kubernetes version: (use kubectl version): n/a
OS (e.g. from /etc/os-release): n/a

/kind bug
/kind documentation

good first issue help wanted kinbug kindocumentation

Source

wfernandes

All 7 comments

@wfernandes: The label(s) kind/ cannot be applied, because the repository doesn't have them

In response to this:

What steps did you take and what happened:
In our documentation we have a list of providers. Here we track the ones that follow v1alpha3 types.

Providers marked in bold are known to support v1alpha3 API types.

However, the list seems to be incorrect because providers like OpenStack and Packet seem to follow the v1alpha3 contract but are not marked as bold.

What did you expect to happen:

Either we should not mark providers that are abiding by the v1alpha3 contract in bold since the list will eventually go out of date and become misleading.
OR

If we want to track what providers are supporting v1alpha3 contracts, we should update this list to ensure we aren't providing misleading information.

Anything else you would like to add:
Is there a way to automate this? With the next release of v1alpha4, should this become a table that's auto generated?

Environment:

Cluster-api version: <=v0.3.8

Minikube/KIND version: n/a

Kubernetes version: (use kubectl version): n/a

OS (e.g. from /etc/os-release): n/a

/kind bug
/kind documentation

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.