https://pulumi.com logo
p

proud-pizza-80589

06/05/2023, 9:16 AM
Super random question, we are running something with pulumi for a client in an airgap environment. So we make sure the plugins are installed in a docker container we use to run refresh and then upgrade with the automation api. But, it appears refresh uses the plugin used when installing the first time, and i guess upgrades on the upgrade run. Is there a way to force it to use the current one for both?
l

limited-rainbow-51650

06/05/2023, 9:45 AM
@proud-pizza-80589 the general gist using Pulumi SDKs is that the SDK tries to use the matching provider binary version. If you start with v1.0 and upgrade the SDK to v1.1, you will need both provider binary versions in your Docker image. The reason is that newer SDK version can introduce newer resources, new resource properties and these are supported by the the newer provider binary.
p

proud-pizza-80589

06/05/2023, 9:47 AM
just for refresh or also for up?
l

limited-rainbow-51650

06/05/2023, 9:49 AM
Even after upgrading your code to a newer SDK version, you can sometimes see Pulumi use the old and new provider binary version. The old version is stored in your state file and is used to read the state of your resources using the old provider binary version. After you apply changes during a
refresh
or
up
, the new provider binary version is updated in your state as well.
p

proud-pizza-80589

06/05/2023, 9:50 AM
damn, that means for an airgap environment i need to pre-install all versions ever in the docker container as i have no idea which version was used
e

echoing-dinner-19531

06/05/2023, 10:53 AM
Yeh we use old versions of the plugin when handling deletes, This ensure that if a type is removed between say version 1 and 2 we can still correctly delete the resource using the version 1 plugin.
l

limited-rainbow-51650

06/05/2023, 10:56 AM
@proud-pizza-80589 here is a handy
jq
query by which you can filter out provider versions from Pulumi state files (JSON):
.deployment.resources | map(select(.type | startswith("pulumi:providers")) | { "provider":.type, "version": .inputs.version})
This should give you other JSON like this:
Copy code
[
  {
    "provider": "pulumi:providers:aws",
    "version": "5.30.0"
  }
]
p

proud-pizza-80589

06/05/2023, 10:58 AM
the challenge with this is that i need to build the list at build time, and the state file is on a disk in an airgap environment somewhere across the world
AFAIK i have the following options: • walk my git history and get the versions out of my package json file to install them • fetch a release list from github to get all released version numbers (we install all updates with renovate) and install them
but my container is going to get huge over time
e

echoing-dinner-19531

06/05/2023, 11:04 AM
Could you ask the airgaped environment to run a query for the oldest version of plugins used in all their state files and then just install everything more recent than that? We have considered only using the most recent plugin version (i.e. which ever one the program specifies) but that changes the requirements on providers to ensure they never drop support for an old resource type, so if we added an option to run in that mode now it would be unsafe.
p

proud-pizza-80589

06/05/2023, 11:06 AM
another challenge than, there are many of such airgapped clients, with each their own versions depending when they installed the first time. I'm just going to scrape the github releases pages, for recent versions and go from there