Support generic resource references in name reference tracking

[yhrn]

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]

@natasha41575 Is this related to #3280?

[natasha41575]

@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

[yhrn]

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.

[fejta-bot]

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

[yhrn]

/remove-lifecycle stale

[yhrn]

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.

[Shell32-Natsu]

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

[yhrn]

@Shell32-Natsu thanks for the response and I understand. But I take it that you agree that the functionality would make sense then.

[Shell32-Natsu]

@monopole Could you please take a look if you have time?

[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

[yhrn]

/remove-lifecycle stale

[KnVerey]

Note that the problem of generic resource reference support is not exclusive to CRDs, as some built-in types contain generic references. See #4254 for an example of how this is currently causing a problem.

/retitle Support generic resource references in name reference tracking

[natasha41575]

/lifecycle frozen

[natasha41575]

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.

[apelisse]

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.

[natasha41575]

@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?

[k8s-triage-robot]

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

[apelisse]

/triage accepted

[davinkevin]

I do a +1 on this issue, especially for the part about role described in #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 😇

[k8s-triage-robot]

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