helm: helm dependency update fails after helm upgrade
Hi
I’m using Helm from Concourse pipeline I just upgraded Helm to 2.6.1 (from 2.4.2) and my pipeline doesn’t work anymore. The culprit line seems to be https://github.com/kubernetes/helm/blob/v2.6.1/pkg/downloader/manager.go#L220
$ helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "ci" chart repository
...Successfully got an update from the "local" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Error: Unable to move current charts to tmp dir: rename /tmp/build/put/staging-helm/cvhub-api/charts /tmp/build/put/staging-helm/cvhub-api/tmpcharts: invalid cross-device link
I cannot change the path used by Concourse but if I do the same command manually on my mac from my home directory (i.e not from /tmp) it works:
% ~/Downloads/helm dependency update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "ci" chart repository
...Successfully got an update from the "local" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading elasticsearch-singlenode from repo http://127.0.0.1:8879
±|develop ✘| cvhub-api
% pwd
/Users/nsitbon/github/cvhub-api/scripts/helm/cvhub-api
As far as I understand the error and the related code it seems that you should not use Rename rather you should use Move.
Any help would be appreciated.
Best regards.
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 46 (24 by maintainers)
Commits related to this issue
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
- Deploys project on GKE 1.15.7 This change fixes a problem whereby deployment of the marketplace app would fail on GKE clusters with Kubernetes versions >= 1.15. The main problem was that we were usi... — committed to cyberark/conjur-google-cloud-marketplace by deleted user 4 years ago
I ran into this as well but was a little baffled by it because source and target are on the same mount point in this concourse scenario.
I think the problem is that the mount point is an overlayfs filesystem (thats how concourse passes inputs into task containers).
I found this in the (unrelated) docker docs in the working with overlay section:
Issues go stale after 90d of inactivity. Mark the issue as fresh with
/remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.If this issue is safe to close now please do so with
/close.Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale
Thanks for the ping @chriscone.
For reference, here is the PR (had to go looking to find it again): https://github.com/helm/helm/pull/5038
The PR introduces code from dep, which is BSD-licensed code and is okay to re-license it as Apache 2 code. The problem at hand, though, is that we’re unsure if copying code from
internal/fsfollows the DCO.I can’t recall who was looking into this, but it probably fell through the cracks. I’ll open a ticket with the CNCF service desk and see if we can get the legal team to weigh in on this topic.
This issue is happening to me when running a docker run command only in Docker for mac. Same command on a linux env work with no problem at all.
I think implementing https://github.com/golang/dep/blob/5b1fe9e6d89372487d0aac78d9c5362a517857e7/internal/fs/fs.go#L103-L118 in helm code would be a quick win.
A simple workaround for me (which I didn’t see above), was to just remove the
chartsdirectory - or add it to something like.dockerignoreto not copy it in the first place (if it’s part of a Docker build). May not work for everyone.Is there something I can do to help with getting this fix merged?
Ah, found one: manually call helm package on dependencies, specifying the destination
chart/directory of the parent chart.dep has a convenient function called
RenameWithFallbackwhich will fall back to a copy-and-remove operation in the case of a cross-device link error. This should be a relatively quick fix if someone wants to take a crack at it!This should be a relatively quick fix. I know what’s causing this. I’ll make a PR this morning.