Giters

kubernetes-retired / multi-tenancy

A working place for multi-tenancy related proposals and prototypes.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow inclusive configuration of resources to propagate

hferentschik opened this issue · comments

commented

When synchronizing additional resource types, eg Secrets, it is currently only possible to configure this globally (see #1435) and the propagation configuration only allows to exclude certain resources from propagation (via annotation).

It would be nice to have an inclusive way of configuring propagation as well. For example, assume the root namespace contains multiple secrets and I would like to only propagate specific secrets (something like what reflector does). In this case I would like to annotate the Secret to propagate and maybe somehow configure to which child namespaces it should be propagated.

This might require changing the propagation modes and adding a new one.

commented

Yes, this is a good idea and we considered it when we were first designing exceptions:

In addition, we will consider adding a global AllowPropagate mode to HNCConfig. This could be useful for types such as Secrets that we don’t want to always propagate. When the propagation mode is Propagate, objects will always be propagated unless an annotation is set; in AllowPropagate, the reverse is true and the objects will only be propagated if an annotation is set. If we do this, we’ll also a propagate.hnc.x-k8s.io/all=true annotation to allow an object to opt into full propagation.

We haven't seen a strong demand from this from our own customers, but I think the interface and semantics are fairly clear so I'd welcome PRs for this feature. Note that the majority of the work here would likely be in coming up with suitable integration tests; the code itself would likely be relatively easy.

/good-first-issue

commented

@adrianludwin:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

Yes, this is a good idea and we considered it when we were first designing exceptions:

In addition, we will consider adding a global AllowPropagate mode to HNCConfig. This could be useful for types such as Secrets that we don’t want to always propagate. When the propagation mode is Propagate, objects will always be propagated unless an annotation is set; in AllowPropagate, the reverse is true and the objects will only be propagated if an annotation is set. If we do this, we’ll also a propagate.hnc.x-k8s.io/all=true annotation to allow an object to opt into full propagation.

We haven't seen a strong demand from this from our own customers, but I think the interface and semantics are fairly clear so I'd welcome PRs for this feature. Note that the majority of the work here would likely be in coming up with suitable integration tests; the code itself would likely be relatively easy.

/good-first-issue

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.

commented

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

commented

@adrianludwin: Closing this issue.

In response to this:

Moved to kubernetes-sigs/hierarchical-namespaces#16

/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.