Exceptions support for GVK

[RealHarshThakur]

Currently, we have support for exceptions but only for a particular resource . It would be nice to have it for entire GVK since we don't have support for multiple HNCConfiguration .

If we had multiple HNCConfiguration, here's what I would do :

• I would like to have the HNCConfiguration named config-A which can propagate config maps/secret/custom resource , roles and rolebindings .
• For the second HNCConfiguration named config-B , I don't want to propagate the config map/secret/custom resource objects , but just the roles/rolebindings .

It might be relatively simpler to have support for exceptions for GVK as opposed to having different configs.

[adrianludwin]

Thanks @RealHarshThakur. Just a small correction - every namespace can have a HierarchyConfiguration, which currently only has two interesting fields:

• The parent of the namespace
• Whether or not cascading deletion is enabled

GVK propagation (technically Group/Resource propagation) is currently controlled by HNCConfiguration. There's only one HNCConfiguration object per cluster.

From an API perspective, we could take the HNCConfigurationSpec object, duplicate it, and add it to HierarchyConfiguration. This would allow every namespace to indicate which kinds of resources it wants to propagate.

The problem then becomes: how do we handle conflicts and changes?

• If the cluster-wide config says secrets should be in the Remove mode, can a namespace override it?
• If you move a namespace from a parent that doesn't propagate secrets to another parent that does, and this would cause a secret in the child namespace to be overwritten, would we catch that? What about in that namespace's descendants?
• Should you be able to turn on propagation of some object type that hasn't been allowed by the cluster admin? E.g. can I turn on propagation for Pod in my namespace (a terrible idea) without my cluster admin approving that first?

So from an API perspective, I think we can make this work pretty easily. The complicated bit is going to be defining what the behaviour should be and then implementing that robustly. Does that all make sense?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

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