Open SanjayVas opened 2 years ago
/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 LoadRestrictionsNone
resolves 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:
kustomization.yaml
by replacing symlinkshttps://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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
/reopen /remove-lifecycle rotten
@sanmai-NL: You can't reopen an issue/PR unless you authored it or you are a collaborator.
@SanjayVas could you please reopen?
@SanjayVas could you please reopen?
/reopen /remove-lifecycle rotten
@SanjayVas: Reopened this issue.
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
/triage accepted
(org members only)/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
Describe the bug
kustomize build
returns the following error when run in a directory where akustomization.yaml
file exists, but is a symlink rather than a regular file.It works as expected when
kustomization.yaml
with the same contents is a regular file.Kustomize version
v4.4.1
Platform
Linux