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

Support multiple clusters in a single namespace #667

Closed
vincepri opened this issue Jan 9, 2019 · 3 comments
Closed

Support multiple clusters in a single namespace #667

vincepri opened this issue Jan 9, 2019 · 3 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@vincepri
Copy link
Member

vincepri commented Jan 9, 2019

/kind feature

On Wed 9 January 2019 meeting, the group discussed to potentially revert the assumption that clusters and machines living in the same namespace are tied together.

Some meetings notes:

This is the PR that implemented the cluster-machines namespace #481
Related: #177
Do we want a tighter relationship between clusters / machines so that we can have multiple clusters in a single namespace
[ashish] When I started the above PR, the consensus was that we wanted one cluster per namespace #252 (comment)
[ashish] more context on the issue #252
[vince] That is the current assumption. Do we want to make that official?
[robert] Hardik has mentioned that Gardener found it useful to put multiple clusters into a namespace so that things like references to secrets can be shared
[justinsb] We may want to get an api reviewer to take a look at our API and help us answer some of these types of questions. I'm not sure if there are other examples of singletons.
[detiber] If we create a link between the two we should be aware of the use case of using machines without clusters and we'd need to make the link optional
[robertbailey] We could use labels to match them up
[robertbailey] Even if there are examples of singletons, they certainly aren't commonplace
[justinsb] kops wouldn't object to creating a dummy cluster object if necessary to adopt the machines api
[robertbailey] the other use case is to put cluster and machine resources in different kubernetes universes; so then the link would also need to be optional
[vince] If we use the label, then providers can adopt them over time
[justinsb] Label selectors are great for many-many which doesn't work well here. Maybe have a field that just points to the owning cluster (even across universes). If it doesn't exist fall back to existing behavior of same-namespace

The goal of this issue is to get an agreement if we want to support multiple clusters in a single namespace. A followup issue, after this one is closed, will be opened to discuss implementations.

@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Jan 9, 2019
@vincepri
Copy link
Member Author

/close

@k8s-ci-robot
Copy link
Contributor

@vincepri: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@zexi
Copy link

zexi commented Jan 18, 2019

Do we have a plan to implement this feature?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants