https://pulumi.com logo
Join Slack
Powered by
is it required to have the older version of a plug...
# general
b
is it required to have the older version of a plugin available to destroy an older stack? got this report from an engineer today:
Copy code
error: could not load plugin for azure provider 'urn:pulumi:compute-g-prod-weu::compute::pulumi:providers:azure::default': no resource plugin 'azure-v0.17.2' found in the workspace or on your $PATH, install the plugin using `pulumi plugin install resource azure v0.17.2
--
running `pulumi plugin install resource azure v0.17.2` inside the container fixed it
he was using the container we built for pulumi which only had 0.17.4 installed
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