kubernetes-sigs
Support generic resource references in name reference tracking
Is your feature request related to a problem? Please describe.
We are working a lot with Google Config Connector and many of the CRDs include references to other resources. In some cases the type of the reference target is implied and in these cases Kustomize's name reference transformer can easily be configured to understand the reference and support prefixing/suffixing. However, for some cases a CR can reference an arbitrary resource by specifying apiVersion/kind in addition to the name, e.g. an IAMPolicyMember which can reference any of ~100 different resource kinds, there seems to be no clean way of configuring name transformation. See below for an example:
apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
name: iampolicymember-sample-pubsubadmin
spec:
member: serviceAccount:[email protected]
role: roles/editor
resourceRef:
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
name: iampolicymember-dep-pubsubadmin
Describe the solution you'd like
It would be great if nameReference supported picking up the target kind/apiVersion/group/version via the field specs instead.
@Shell32-Natsu tangentially related to #3280 only in that they both deal with refactoring the name reference transformer. Apart from that I don't think the solutions overlap
One more thing to consider here if we're talking refactoring is that currently the namespace of a reference has to be handled by a separate namespace transformer. I think this happens to work in most cases because typically name transformations are applied the same way across all resources in a Kustomization but it feels a bit fragile.
It would feel more natural if there was a reference transformer that understood referencing via the complete set of attributes needed to identify an object; name, namespace, kind and group. I'm not sure if version is really relevant for identifying an object but references typically use apiVersion which drags it in anyway so it probably needs to be dealt with somehow.
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
Sorry if I appear to be nagging but I'm not sure how the triage process works here. Is this something you would consider adding? It's a pretty important use case for us and I think it would make Kustomize a much more powerful tool when used together with Google Config Connector resources and probably other similar products for other cloud vendors.
@yhrn I apologize for the situation. We are in an extremely short of hands. Our resources are mainly focusing on fixing bugs and refactoring to re-integrate with kubectl. We hope we can eventually add more new features like this.
@Shell32-Natsu thanks for the response and I understand. But I take it that you agree that the functionality would make sense then.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
Note that the problem of generic resource reference support is not exclusive to CRDs, as some built-in types contain generic references. See https://github.com/kubernetes-sigs/kustomize/issues/4254 for an example of how this is currently causing a problem.
/retitle Support generic resource references in name reference tracking
I am working on a design proposal to resolve this issue - it will be submitted as a KEP when it is ready. Thank you for your patience, I know it's been a really long wait for this feature.
I am working on a design proposal to resolve this issue - it will be submitted as a KEP when it is ready. Thank you for your patience, I know it's been a really long wait for this feature.
Please keep me in the loop, I've seen various efforts related to this and would love to see one succeed.
@apelisse There are still various discussions going on internally, and I was thinking about somehow supporting this feature through the openapi field (which is where we currently support custom merge keys). I remember at one point seeing a document - possibly authored by you - regarding including object references in the openapi data served by the apiserver. Has there been any news on that effort?
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
- Confirm that this issue is still relevant with
/triage accepted(org members only) - Close this issue with
/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
I do a +1 on this issue, especially for the part about role described in https://github.com/kubernetes-sigs/kustomize/issues/4254.
It's very annoying to have this bug, because we want to use the suffix but we also have deployment & others named the same as configMap/Secret… and this is where the bug appears.
Thank you for your work, really hope to see the fix soon for this part 😇
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
- Confirm that this issue is still relevant with
/triage accepted(org members only) - Close this issue with
/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted