This message was deleted.

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

just for refresh or also for up?

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.

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

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.

@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:

[
  {
    "provider": "pulumi:providers:aws",
    "version": "5.30.0"
  }
]

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

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.

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