Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KRM functions are behaving differently for exec and container functions #5371

Open
xvzf opened this issue Oct 10, 2023 · 7 comments
Open

KRM functions are behaving differently for exec and container functions #5371

xvzf opened this issue Oct 10, 2023 · 7 comments
Assignees
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@xvzf
Copy link

xvzf commented Oct 10, 2023

What happened?

The -e ENV_VAR=VALUE flag is exposed to container KRM functions as an environment variable, while it is dropped for exec-based functions.

What did you expect to happen?

Container and Exec KRM functions behave the same

How can we reproduce it (as minimally and precisely as possible)?

Here's a repository with the full configuration and example commands to replicate this: https://github.com/xvzf/kustomize-krm-script-example

Expected output

See repo above

Actual output

See repo above

Kustomize version

5.1.1

Operating system

None

@xvzf xvzf added the kind/bug Categorizes issue or PR as related to a bug. label Oct 10, 2023
@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Oct 10, 2023
@xvzf
Copy link
Author

xvzf commented Oct 10, 2023

This issue would be addressed by #5316

Ping @koba1t

@xvzf xvzf changed the title KRM functions are behaving differently for exec and contains KRM functions are behaving differently for exec and containers Oct 10, 2023
@xvzf xvzf changed the title KRM functions are behaving differently for exec and containers KRM functions are behaving differently for exec and container functions Oct 10, 2023
@koba1t
Copy link
Member

koba1t commented Oct 21, 2023

Thanks @xvzf!
I'll check the details.

@natasha41575
Copy link
Contributor

/assign @varshaprasad96

@xvzf
Copy link
Author

xvzf commented Nov 9, 2023

@varshaprasad96 can you consider re-opening my PR? Happy to work on it :)
#5316

@varshaprasad96
Copy link
Member

Hello @xvzf, I was investigating this feature to check if there will ever be a scenario where the env var and input argument (through the annotation) be the same. In this case, looks like any argument cannot be passed from the annotation itself because of an implementation detail. To elaborate what I mean:

Consider the scenario where generator looks like:

apiVersion: myDevOpsTeam
kind: SillyConfigMapGenerator
metadata:
  name: whatever
  annotations:
    config.kubernetes.io/function: |
      exec: 
        path: ./plugins/silly-generator.sh --test=<something>
spec:
  altGreeting: Bienvenue
  enableRisky: true

In this case, kustomize build will error with: Error: couldn't execute function: fork/exec ./plugins/silly-generator.sh --test: no such file or directory. Looks like the annotation value is directly passed as is, in the filter path (

identifier = filter.Path
) instead of breaking into args, to be executed here:
cmd := exec.Command(c.Path, c.Args...) //nolint:gosec
. Given this, I believe it would be safe to make the behaviour same for containerized and exec based KRM functions.

Thanks for working on the PR. I don't have permissions to re-open it. Probably @natasha41575 / @koba1t can? If not, you can open a new one and reference the issue.

@koba1t
Copy link
Member

koba1t commented Nov 23, 2023

Thanks @varshaprasad96
I reopened that PR!

@natasha41575
Copy link
Contributor

/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Nov 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Categorizes issue or PR as related to a bug. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

No branches or pull requests

5 participants