search

kubernetes-retired / cluster-registry

[EOL] Cluster Registry API
https://kubernetes.github.io/cluster-registry/
Apache License 2.0
238 stars 94 forks source link

Namespace the Cluster resource #202

Closed perotinus closed 6 years ago

perotinus commented 6 years ago

/sig multicluster

In my testing, this seemed to worked fine in both aggregated and standalone modes.

/cc @pmorie @madhusudancs @font

k8s-ci-robot commented 6 years ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: perotinus

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/kubernetes/cluster-registry/blob/master/OWNERS)~~ [perotinus] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment
madhusudancs commented 6 years ago

What proposal is this based on? Did we come to a consensus about this?

perotinus commented 6 years ago

@madhusudancs This doc has the discussion, though it is not a formal proposal. I shared it with the SIG about three weeks ago, and haven't gotten anybody arguing strongly in favor of cluster scoping. IMO, @pmorie's arguments against the disadvantages of moving to a namespaced API were convincing enough, and the need to authorize subsets of clusters seems only to be solvable by introducing namespaces.

Part of the goal of this PR was to force a consensus. My initial intention with this code was to experiment with the namespaced API, but once the work was done and I did not discover any issues, I figured it would help move the conversation along to push the code for others to review.

madhusudancs commented 6 years ago

@perotinus alright makes sense. Here is my argument https://docs.google.com/a/google.com/document/d/1rT7WnWqZdqCP3Wl-NEvEb6fyP7DbDOp_Tkpc5eA5GTI/edit?disco=AAAABnJ1AWI against namespaces in CR.

perotinus commented 6 years ago

Closing in favor of #228, which builds on #225.