search

kubernetes / org

Meta configuration for Kubernetes Github Org
Apache License 2.0
242 stars 690 forks source link

New repo sigs.k8s.io/cluster-api-provider-nested #2247

Closed christopherhein closed 4 years ago

christopherhein commented 4 years ago

New Repo, Staging Repo, or migrate existing

new repository

Requested name for new repository

cluster-api-provider-nested

Which Organization should it reside

kubernetes-sigs

If not a staging repo, who should have admin access

If not a staging repo, who should have write access

If not a staging repo, who should be listed as approvers in OWNERS

If not a staging repo, who should be listed in SECURITY_CONTACTS

What should the repo description be

"Cluster API Provider for Nested Clusters"

What SIG and subproject does this fall under in sigs.yaml

sig-cluster-lifecycle

Approvals

Wed Oct 7th, 2020 Agenda item to understand the requirements to get a new repo.

This was brought up for feedback looking to timothysc for some next steps.

Additional context for request

This repo is meant to house the reimplemented Cluster API Provider for Virtual Cluster, which currently implements a bespoke API. This API is being redesigned using Cluster API and implementing a VirtualControlPlane type that will create nested control planes within clusters. This will also bring over the syncing logic which helps to turn a large cluster into a multi-tenant scheduling domain that each of the virtual clusters can use.

We're asking for a repo before the new implementation is done so that we can build this with better practices, working groups technically aren't supposed to "own" code implementations and because this repo also contains HNC and a tenant controller it's difficult to use best practices like CI and build pipelines.

Original Code base: https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster More information: https://www.cncf.io/blog/2019/06/20/virtual-cluster-extending-namespace-based-multi-tenancy-with-a-cluster-view/ KubeCon EU 2020: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/schedule/

❤️

timothysc commented 4 years ago

/assign @timothysc @neolit123

vincepri commented 4 years ago

+1

CecileRobertMichon commented 4 years ago

+1

Any thoughts on what acronym the provider will use? CAPV is already taken by https://github.com/kubernetes-sigs/cluster-api-provider-vsphere

christopherhein commented 4 years ago

@CecileRobertMichon looking at CAPI docs and acronyms, what about CAPVC?

vincepri commented 4 years ago

CAPVC sounds good to me, or we can also just call it CAPVirtual 😄

christopherhein commented 4 years ago

Yeah, @vincepri that would work too

neolit123 commented 4 years ago

i see +1s from CAPI maintainers and no objections, but have the CAPI maintainers reviewed the code base of the migrated repository to see if it matches expectations for an infrastructure provider?

christopherhein commented 4 years ago

@neolit123 today it doesn't, we're in the process of re-implementing the API layer to move toward a Cluster API spec for an infra provider and a control plane provider (I have been working with @vincepri on this definition) but given the nature around working groups owning code its difficult to dev on the project cause we don't have CI processes along with other projects within https://sigs.k8s.io/multi-tenancy/incubator/virtualcluster (HNC, tenant controller, and virtual cluster)

neolit123 commented 4 years ago

ok, thanks for the details. i should be corrected if i'm wrong here, but historically we had somewhat working providers before promoting them to a k-sig/cluster-api-provider-* repository, @vincepri @detiber @timothysc do you see this as a concern? my personal preference would be to have the provider working, but i may be mistaken about the prior art.

in any case, this does seem to belong in a CAPI provider repository and something that CAPI maintainers should shepherd under SIG CL.

another question from my side is about naming. should we reserve -virtual for this implementation or something else in the future may come also revolving around the "virtual" topic? should we be more explicit in the naming - e.g. -virtual-cluster (which also matches the proposed CAPVC abbrev.)?

christopherhein commented 4 years ago

I'd be fine going the cluster-api-provider-virtual-cluster path if we want to reserve -virtual for something else. If everyone agrees I can update the description and title.

neolit123 commented 4 years ago

we had a zoom call with @vincepri @timothysc and @christopherhein and discussed that the -virtual-* name is not ideal. "-nested" was proposed and we agreed that this is a better name!

@christopherhein please update the requested repo name to cluster-api-provider-nested

the concept of the project was also explained to me and i like the idea so +1.

christopherhein commented 4 years ago

thanks @neolit123, @vincepri, and @timothysc !

timothysc commented 4 years ago

Post call +1 /lgtm /approve

vincepri commented 4 years ago

+1

nikhita commented 4 years ago

Repo has been created - https://github.com/kubernetes-sigs/cluster-api-provider-nested :tada:

Also created:

Once both PRs merge, we can close this issue.

nikhita commented 4 years ago

Teams have been granted access and sigs.yaml has been updated. Closing!

christopherhein commented 4 years ago

Thanks @nikhita !