Exec KRM function in 'generators:' don't get passed items from 'resources:' via ResourceList['items']

[vugardzhamalov]

Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

Greetings everyone!

At the moment of writing I am on Kustomize version 5.3.0

I was looking at Exec KRM function example provided here.

I've made a few observations and I was wondering if someone could please clarify if following is expected/by design:

1. None of the items declared under 'resources:' will end up passed by Kustomize to KRM function in ResourceList['items'] if your plugin configuration was declared as one of the items under 'generators:'
2. The same plugin configuration declared under 'generators:' will end up passed both!!! as ResourceList['functionConfig'] and!!! as ResourceList['items'] - there it will end up as a first and only item in the list.

Why is this needed?

It will be nice to have above clarified because as far as I can see it - this is different from Kustomize behavior I am observing when my plugin configuration goes as one of the items under 'transformers:' list (once again as oppose to 'generators:').

When I use 'transformers:' I will end up with all of my items (no matter declared under 'resources:' and 'generators:' and 'transformers:') passed to my KRM function under ResourceList['items']. And as far as I can see it - inside ResourceList['items'] they will be indexed in the same order.

Also please keep in mind that plugin configuration declared under 'transformers:' does NOT get passed to ResourceList['items'] - once again this is different from behavior observed for plugin configuration declared under 'generators:'

Mind you though I haven't tried any of these with 'components:' and/or 'validators:' yet.

Can you accomplish the motivating task without this feature, and if so, how?

Well yes I think I can - as long as we understand the difference (I am guessing by design) in Kustomize behavior when using KRM functions under 'generators:' as opposed to plugin configurations placed under 'transformers:'

What other solutions have you considered?

I wonder if it will be better to allow for the end user to have a final word (say via annotations or some other manner) over what Kustomize should exclude/include, if we would like to include/exclude all or some of the items (no matter from 'resources:' and/or 'generators:' and/or 'transformers:') and pass it further via ResourceList['items']

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue 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.

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue 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 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 with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages issues 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 with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

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-sigs/prow repository.