Org: New repo sigs.k8s.io/cluster-api-provider-nested

[christopherhein]

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

• christopherhein
• Fei-Guo
• https://github.com/kubernetes-sigs/cluster-api/blob/master/OWNERS_ALIASES

If not a staging repo, who should have write access

• christopherhein
• Fei-Guo
• resouer
• zhuangqh
  (we'll likely want to make a team for this in the long term for maintaining this group, TBD)

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

• christopherhein
• Fei-Guo
• resouer
• zhuangqh
• https://github.com/kubernetes-sigs/cluster-api/blob/master/OWNERS_ALIASES

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

• christopherhein
• Fei-Guo
• https://github.com/kubernetes-sigs/cluster-api/blob/master/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]

/assign @timothysc @neolit123

[vincepri]

+1

[CecileRobertMichon]

+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]

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

[vincepri]

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

[christopherhein]

Yeah, @vincepri that would work too

[neolit123]

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]

@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]

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]

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]

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]

thanks @neolit123, @vincepri, and @timothysc !

[timothysc]

Post call +1
/lgtm
/approve

[vincepri]

+1

[nikhita]

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

Also created:

• https://github.com/kubernetes/org/pull/2249 - to add GitHub teams to provide access
• https://github.com/kubernetes/community/pull/5202 - to add the repo to sigs.yaml

Once both PRs merge, we can close this issue.

[nikhita]

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

[christopherhein]

Thanks @nikhita !