https://pulumi.com
Join Slack
This message was deleted.
# general
s
This message was deleted.
w
Yes - you do. That said, I would have expected we were downloading it if needed. cc @incalculable-sundown-82514 in case he has thoughts on this.
b
following up @incalculable-sundown-82514 - is this related to the same issue https://github.com/pulumi/pulumi/issues/2608 ? Since we use a portable docker container with pulumi embedded (and usually the latest CLI and plugins) if the system isn’t supposed to auto-download, that would make it quite a bit more challenging for us.. I assume we’d to have every version ever released installed in the container. Can you clarify?
i
The issue you linked only happens if you have a non-standard Node project setup - is that the case inside your Docker container?
b
yes for the linked issue it’s as we discussed previously where the package.json is above the project folder
it’s the same setup for this new issue we’re seeing where the destroy of an older stack fails because the plugin isn’t installed
for the linked issue i wrote code to parse the stack contents and prune old plugins as part of our pipeline
for today’s issue, i dont know what the fix would be - which is why I’m inquiring
i
then yes. The only plugins you need to install are the ones explicitly mentioned in your npm package-lock.json.
ones required by your state ("old" resources) should be downloaded on-demand.
b
hmm.. ok that didn’t seem to happen then per the issue report I received.. it didn’t appear to be downloaded automatically
i’ll just keep an eye on it and see if it crops up again, maybe the user did something weird
thanks
hi @incalculable-sundown-82514 ok, so at least i’ve narrowed this down a bit - I have our pipeline using Pulumi in a docker container. That container usually only has the latest plugins installed. For our automated teardown, i’ve been doing a 
pulumi refresh
beforehand, seems to be a good idea to correct any drift, but if the version is old, then it fails. Is this supposed to automatically install the old plugin in this case?
(getting you a link of logs 1 sec)
I do have the “nonstandard” setup as described in this issue: https://github.com/pulumi/pulumi/issues/2608 - am I correct in assuming that once #2608 is solved that this issue will likely be solved as well? In the meantime, it appears the destroy works correctly.. so if I remove the “refresh” step on the teardown, i can probably work around it
i
Yes, that’s correct, although we could probably do better with 
refresh
. Can you open an issue for that?
b
ok thanks, I’ll post the pastebin log and explain the issue then
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by