kubernetes-sigs
[Linux only] kustomization.yaml not found if it's a symlink
Describe the bug
kustomize build returns the following error when run in a directory where a kustomization.yaml file exists, but is a symlink rather than a regular file.
Error: unable to find one of 'kustomization.yaml', 'kustomization.yml' or 'Kustomization' ' in directory
It works as expected when kustomization.yaml with the same contents is a regular file.
Kustomize version
v4.4.1
Platform
Linux
/retitle [Linux only] kustomization.yaml not found if it's a symlink
This issue doesn't exist on OSX, but I was able to reproduce on Linux.
/triage accepted
Doing some digging, I think the problem is in loadKustFile. More specifically, the RestrictionRootOnly load restrictor might be applying to the resolved real path of my kustomization.yaml symlink. Indeed, passing --load-restrictor LoadRestrictionsNone to the command avoids this error.
Given the description of the --load-restrictor option to be concerned with relocatability, I would RestrictionRootOnly to care about the path of the symlink itself rather than of the resolved target.
I think there may be other cases that aren't handled by changing the load restrictor, e.g. referencing other files in the kustomization.yaml that are symlinks.
I believe this prevents running kustomize from Bazel, as Bazel relies heavily on symlinking to put both generated and hand-written source files in the "same location".
Just to confirm it does prevent you from using kustomize in Bazel without workarounds. --load-restrictor LoadRestrictionsNone resolves this issue in bazel.
--load-restrictor LoadRestrictionsNoneresolves this issue in bazel.
I don't think this is true. There's some other issues with symlink resolution. If you have a mix of generated and source files, things get screwy since some of those get symlinked. Kustomize appears to expect all paths to be relative to the resolved location rather than the symlinked one.
The only workaround I've found is to copy all the files to a single tree (in Bazel, this means tarring them up and extracting them later).
Sorry I did not to meant to say it resolves all possible issues. In our case we do not have generated files, so the only issue is this issue of kustomization.yaml not being found if its a symlink. Constructing a source tree for the rule does sound like the safest bet.
Any efforts towards making kustomize work better in bazel builds are much appreciated! Thanks for the tip on the workaround.
Not supporting symlinks has been a hindrance for quite a long time... and it's still the case on the very latest version of kustomize v.4.5.5.
Symlinks are a core part of unix administration, use cases include:
- testing different adjacent versions of
kustomization.yamlby replacing symlinks - a repo full of different kustomizations that I would like to just symlink to a working directory and execute, eg:
https://github.com/HariSekhon/Kubernetes-configs
Workarounds such as cp instead of ln are not ideal, because you are duplicating contents and then have to keep both copies up to date - this is exactly the sort of thing symlinks were designed to solve.
I'm not familiar with the Kustomize code base but am hoping it's a fairly easy file existence call check to fix this?
Until kustomize build behavior is changed, kustomize localize will follow the kustomize build standard and not accept files that are symlinks to locations outside the kustomization root.
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
The Kubernetes project currently lacks enough active 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 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 rotten
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/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:
- 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-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/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou 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/test-infra repository.
@sanmai-NL: You can't reopen an issue/PR unless you authored it or you are a collaborator.
In response to this:
/reopen /remove-lifecycle rotten
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.
@SanjayVas: Reopened this issue.
In response to this:
@SanjayVas could you please reopen?
/reopen /remove-lifecycle rotten
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.