Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming repositories for cloud specific code #383

Closed
kris-nova opened this issue Jun 22, 2018 · 15 comments
Closed

Naming repositories for cloud specific code #383

kris-nova opened this issue Jun 22, 2018 · 15 comments

Comments

@kris-nova
Copy link
Contributor

@kris-nova kris-nova commented Jun 22, 2018

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

This comment has been minimized.

Copy link
Contributor Author

@kris-nova kris-nova commented Jun 22, 2018

Vote for 1)

@kris-nova

This comment has been minimized.

Copy link
Contributor Author

@kris-nova kris-nova commented Jun 22, 2018

Vote for 2)

@kris-nova

This comment has been minimized.

Copy link
Contributor Author

@kris-nova kris-nova commented Jun 22, 2018

Vote for 3)

@dims

This comment has been minimized.

Copy link
Member

@dims dims commented Jun 22, 2018

4) Cluster provider

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

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

This comment has been minimized.

Copy link
Member

@dims dims commented Jun 22, 2018

Vote for 4)

@davidewatson

This comment has been minimized.

Copy link
Contributor

@davidewatson davidewatson commented Jun 22, 2018

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

@roberthbailey

This comment has been minimized.

Copy link
Contributor

@roberthbailey roberthbailey commented Jun 22, 2018

@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

This comment has been minimized.

Copy link
Member

@dims dims commented Jun 22, 2018

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

This comment has been minimized.

Copy link
Contributor

@roberthbailey roberthbailey commented Jun 22, 2018

@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

This comment has been minimized.

Copy link
Contributor

@craigtracey craigtracey commented Jun 23, 2018

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

This comment has been minimized.

Copy link
Contributor

@roberthbailey roberthbailey commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Contributor Author

@kris-nova kris-nova commented Jun 28, 2018

@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

This comment has been minimized.

Copy link
Contributor

@craigtracey craigtracey commented Jun 28, 2018

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

This comment has been minimized.

Copy link
Member

@dims dims commented Jul 2, 2018

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

This comment has been minimized.

Copy link
Contributor Author

@kris-nova kris-nova commented Jul 5, 2018

Closing - with consensus on 3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.