search

kubernetes-sigs / kustomize

Customization of kubernetes YAML configurations
Apache License 2.0
11.01k stars 2.25k forks source link

[Linux only] kustomization.yaml not found if it's a symlink #4420

Open SanjayVas opened 2 years ago

SanjayVas commented 2 years ago

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

KnVerey commented 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

SanjayVas commented 2 years ago

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.

SanjayVas commented 2 years ago

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".

kurt-google commented 2 years ago

Just to confirm it does prevent you from using kustomize in Bazel without workarounds. --load-restrictor LoadRestrictionsNone resolves this issue in bazel.

SanjayVas commented 2 years ago

--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).

kurt-google commented 2 years ago

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.

HariSekhon commented 2 years ago

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:

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?

annasong20 commented 2 years ago

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.

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle stale

k8s-triage-robot commented 2 years ago

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:

You can:

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

/lifecycle rotten

k8s-triage-robot commented 1 year ago

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:

You can:

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

/close not-planned

k8s-ci-robot commented 1 year ago

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

In response to [this](https://github.com/kubernetes-sigs/kustomize/issues/4420#issuecomment-1304638835): >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][1] > >Please send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). > >/close not-planned > >[1]: https://www.kubernetes.dev/docs/guide/issue-triage/ Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
sanmai-NL commented 1 year ago

/reopen /remove-lifecycle rotten

k8s-ci-robot commented 1 year ago

@sanmai-NL: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to [this](https://github.com/kubernetes-sigs/kustomize/issues/4420#issuecomment-1719575147): >/reopen >/remove-lifecycle rotten Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
sanmai-NL commented 1 year ago

@SanjayVas could you please reopen?

SanjayVas commented 1 year ago

@SanjayVas could you please reopen?

/reopen /remove-lifecycle rotten

k8s-ci-robot commented 1 year ago

@SanjayVas: Reopened this issue.

In response to [this](https://github.com/kubernetes-sigs/kustomize/issues/4420#issuecomment-1719774072): >> @SanjayVas could you please reopen? > >/reopen >/remove-lifecycle rotten Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
k8s-triage-robot commented 1 month ago

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted