Kustomize bug was documented as a feature

[KnVerey]

This is a Bug Report

Problem:
Commit b9da040 / PR #30348. That PR documented a bug in Kustomize as though it were a feature, and unfortunately nobody from the Kustomize team saw the PR.

The behaviour in question is considered very problematic and clearly undesirable, as it violates two Kustomize's core principles/guarantees: being a template-free solution and having no build-time side-effects. In fact, in Kustomize's own docs, this behaviour is explicitly documented as something Kustomize will never support: Eschewed Features list.

Both Kustomize maintainers agree on this point, and we were also able to confirm with the person who originally copied the offending code from kubectl that this behaviour came along with that code entirely by accident.

Proposed Solution:

• Revert the PR, with or without a warning about relying on the behaviour (I originally proposed a straight revert, and added the warning at the request of the docs team. I am happy either way, as long as we get this problematic recommendation down ASAP): Revert documentation of Kustomize bug as a feature #35522
• A warning is already being emitted when the behaviour occurs in the latest version of Kustomize: Emit a warning when env loading bug is being relied on kubernetes-sigs/kustomize#4730.

Page to Update:
https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/

[sftim]

/language en
/triage accepted

[sftim]

/priority important-longterm

We need to decide on exactly what the fix will look like.
/sig cli

[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

[sftim]

/remove-priority important-longterm
/priority important-soon

after discussion with SIG CLI

[sftim]

/remove-lifecycle stale

[nikitar]

It seems the issue has been addressed and can be closed, correct? I.e. the documentation change is reverted and a warning is added to Kustomize. Is there anything else that needs to be done?

(Came across this by browsing priority/important-soon)

[sliekens]

How do I add calculated env vars to my deployment without this feature bug? Does Kustomize provide an alternate solution for the removed functionality or is it entirely my responsibility to append a line to the .env file?

For context, I need the Git SHA hash in a ConfigMap. My CI/CD provider makes the SHA available as an env var in the process where I run my Kustomize build.

I was using the passthrough vars.

# kustomization.yaml file
kind: Kustomization
apiVersion: kustomize.config.k8s.io/v1beta1
configMapGenerator:
  - envs:
      - .env
    name: some-configmap
bases:
  - ../../base

# .env file
ELASTIC_APM_SERVER_URL=https://some-apm-instance.elastic-cloud.com
ELASTIC_APM_SERVICE_VERSION

Here, ELASTIC_APM_SERVICE_VERSION is a system environment variable that contains the Git SHA.

[sftim]

Hi @sliekens

GitHub is not the right place for support requests.

If you're mainly looking for advice, you could ask on Server Fault.

You can also post your question on the Kubernetes Slack or the Discuss Kubernetes forum.

[sftim]

/close

This issue is addressed.

[k8s-ci-robot]

@sftim: Closing this issue.

In response to this:

/close

This issue is addressed.

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.

[sliekens]

@sftim fair, but you could still make a general recommendation for users who were relying on removed functionality.