Cluster-api: Naming repositories for cloud specific code

[kris-nova]

So following up on the discussion of creating single repositories for cloud specific cluster API code we need to come up with a standard naming prefix for each of the repositories.

To follow suit with the cloud provider repositories in github.com/kubernetes we probably should stick to a standard syntax.

1. Actuators

Where $cloud is a short acronym for the cloud (EX: gcp, aws, etc)

github.com/kubernetes-sigs/actuators-$cloud

2. Compute provider

Where $cloud is a short acronym for the cloud (EX: gcp, aws, etc)

This is following up on the notion that we have 3 types of infrastructure (storage, network, and compute)

github.com/kubernetes-sigs/compute-provider-$cloud

3. Cluster API provider

Where $cloud is a short acronym for the cloud (EX: gcp, aws, etc)

github.com/kubernetes-sigs/cluster-api-provider-$cloud

4. Other

Add a comment below

---

Tagging folks who are relevant to this discussion and might be able to offer insight if needed

CC: @jbeda @thockin @timothysc @roberthbailey @krousey @rsdcastro @dims

---

Also once we decide on a convention, we will need to determine the best way to get new repositories with the broader sig. I think we are the first project to do this, so we might have to pioneer the process along the way.

[kris-nova]

Vote for 1)

[kris-nova]

Vote for 2)

[kris-nova]

Vote for 3)

[dims]

4) Cluster provider

We really don't need to say api in the name

github.com/kubernetes-sigs/cluster-provider-$cloud

[dims]

Vote for 4)

[davidewatson]

Since the kubernetes-sigs organization is flat, does not including cluster-api in the name make the repos less discoverable?

[roberthbailey]

@davidewatson has a good point. It'd be super convenient to look at https://github.com/kubernetes-sigs?utf8=%E2%9C%93&q=cluster-api&type=&language= and see both the api repo and all of the provider repos with one query.

[dims]

the precedent i was following was what we have for cloud-providers - https://github.com/kubernetes?utf8=%E2%9C%93&q=cloud&type=&language=

[roberthbailey]

@dims - I think the precedent is actually a bit confusing because all of the "cloud-provider" repositories that have README files say that they are the home of the cloud controller manager. So I can't tell if they should have been named cloud-controller-manager-$env or if they will grow to include cloud-specific code that is outside of the cloud controller manager.

Personally, I like the idea of having repos be smaller and more focused and just do one thing well. It makes vendoring simpler, and it makes it easier to compose the repos together.

[craigtracey]

Do we expect there to be alternate implementations of various $cloud? Or what about a controller that handles multiple $clouds? I think this is a real possibility, and perhaps something we should consider.

[roberthbailey]

On the WG call we discussed that it would be nice to put multiple sig sponsored cloud implementations (e.g. AWS) into the same repository (there can certainly be other implementations outside of the CNCF org). I there is a good value in having the community that is working on the same environment have a rallying point.

Can you explain more about how you envision a multi-$cloud controller looking? We have a proposal for an ssh-provider, which is along those lines and we've also talked in the past about using terraform or docker-machine to create a controller that supports new environments with little extra effort. Is it along those lines or something different?

[kris-nova]

@craigtracey do you have any other concerns? We talked about multiple implementations and how they could be supported in a single repository on the call on wed. Would like to get a consensus here so we can start creating repositories.

[craigtracey]

The only point I was driving at (and perhaps this is a nit) was that $cloud might be better served as $name. $name would likely be the name of the provider, but could also be something a bit more specific (ie. aws and aws-govcloud) or a bit more broad (ie. ssh, terraform, etc).

I do expect their to be multiple implementations of the same $cloud, but there is no reason these can't be hosted in private/public orgs.

No additional concerns here. Thanks for checking in!

[dims]

Looks like there is consensus on naming - Option 3 : github.com/kubernetes-sigs/cluster-api-provider-$cloud

Can we please create the repos?

[kris-nova]

Closing - with consensus on 3