Come up with globally valid API groups

[dlipovetsky]

/kind bug

cluster-api/pkg/apis/cluster/v1alpha1/cluster_types.go

Line 26 in 8141304

const ClusterFinalizer = "cluster.cluster.k8s.io"

The API group .k8s.io should not be used by anything other than core Kubernetes.

[ncdc]

Do we want separate issues for the other places we'll need to change (all label keys, all finalizers, the API group itself)? Or lump them all here?

[ncdc]

/priority important-soon
/milestone v1alpha2
/area api

[dlipovetsky]

@ncdc We can lump them all here. I'll update the issue. Can we enumerate the "bad" groups?

cluster.k8s.io
machines.k8s.io

[ncdc]

Anything .k8s.io used as an API group name, label key, finalizer key. That's a good start. We can add more if we find them in the code.

[dlipovetsky]

Got it.

Might providers be using these, too? I realize they'll define their own groups, but if they're using .k8s.io groups anywhere (like labels), we should let them know.

[ncdc]

It's certainly possible. We could check all the CAP* repos in kubernetes-sigs.

[detiber]

sigs.k8s.io is the official alias for kubernetes-sigs projects, so should likely use subdomains of that.
cluster.cluster-api.sigs.k8s.io for example.

Providers could use similar naming as well (assuming they are hosted under kubernetes-sigs):
<something>.cluster-api-provider-aws.sigs.k8s.io

[vincepri]

/assign

Would this break v1alpha1 compatibility if we switch?

[vincepri]

I can switch in #1035, if we find consensus

[detiber]

It will break v1alpha1 compatibility, we should only change for v1alpha2+

[ncdc]

The only way to preserve v1alpha1 compatibility is to not change it, which means keeping v1alpha1 at the old group name, and changing the name for v1alpha2. At that point, we wouldn't have CRD multi-versioning because it'd be 2 different API groups.

[vincepri]

I don't think we can, given that multi-version support requires the same APIGroup 🤔

[ncdc]

We'd create 2 different API groups

[detiber]

We're going to need an external migration anyway since we are breaking out the embedded types and introducing the bootstrapping types.

[vincepri]

Doesn't that mean no webhook conversion though?

[vincepri]

In that case, I'd prefer to keep them under the new type and let the external migration tool handle the change, wdyt?

[ncdc]

I'm not sure conversion webhooks were really on the table given how much of a change this is, and the split from RawExtension to full CRDs will require custom logic per provider.

[ncdc]

keep them under the new type

What do you mean?

[vincepri]

I mean just use the new APIGroup for v1alpha1 and v1alpha2 and let the external tool to change the APIGroup as well

[ncdc]

We have to keep v1alpha1 using the old api group

[detiber]

Yes, we can't change the api group otherwise we lose the connection to the underlying object storage in etcd

[vincepri]

/lifecycle active

[vincepri]

/reopen

[k8s-ci-robot]

@vincepri: Reopened this issue.

In response to this:

/reopen

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.

[timothysc]

the blessed namespace is x-k8s.io
Documentation has been updated and guidelines are also coming from sig-arch
https://github.com/kubernetes/community/blob/master/sig-architecture/api-review-process.md