can someone explain to me the purpose of

--target

? specifically within the context

pulumi up --target

? my understanding is it allows one to target a specific resource for update, but im getting strange behavior/errors like below, which is counterintuitive to me(why is pulumi looking at/reporting on resources outside the

--target

?).

error: Resource 'urn:....' will be destroyed but was not specified in --target list.
    Either include resource in --target list or pass --target-dependents to proceed.

where the resource to be destroyed is not the targeted resource, nor should it be destroyed (it still exists in state and in the unfiltered stack) FWIW, im trying to update a provider (using

up --target

) as a workaround for this known issue where provider stored config is out of date and breaks

refresh

after a secrets rotation.

You're on the right track here: Say you have a storage bucket, and an object in that bucket. If you delete the bucket or make a change to it that requires re-creating it, then the object will be destroyed as well in the process. If you delete a provider, all resources associated with the provider will be removed from the state. If you consider the case where you're dropping a provider, this makes a lot of sense: If there's no provider for a resource type, you cannot manage it. But it causes issues in the situation you describe. What provider are you trying to update?

thanks for the response! i have a postgres provider

urn:pulumi:prd::iac::pulumi:providers:postgresql::some_database

that needs its config updated because of RDS secrets rotation ( i haven't found a clean way to not use the root creds) every 7 days

refresh

breaks, so im trying to "cleanly" update the provider only, basically force a state refresh for the new creds, before running

preview --refresh

the issue is, another ec2 resource, very loosley connected to the provider (still trying to figure this one out) is causing the failure edit: pretty sure the connection is via an aws iam policy.

// some policy allowing an ec2 role to access the password for a postgres user.
    Resource: [
          someUserCreatedByPostgresProvider.passwordSecret.apply(
            ({ secret }) => secret.arn,
          ),
        ],

This sounds like you could break this connection. Perhaps you can work with multiple postgres providers, each for a specific group of resources? They could still use the same credentials (in case that's relevant) but would be logically separated.

i thought about that, but then i have a chicken/egg problem ( i think)

provider1 => uses root creds => creates iam role with RDS access for pulumi
provider2 => uses IAM role => creates database users.

... wait 7 days

refresh errors because provider1 has invalid db creds (after rotation)

edit: technically the providers are connected, but perhaps this would unlock the

--target

option for

provider1

🤔

I typically solve situations like this by having two programs/stacks: One that generates the DB instance and admin credentials, and one that uses the admin credentials to manage the DB.

thats fair 🤔 though i think

refresh

would always break for this stack > One that generates the DB instance and admin credentials assuming it uses the root creds from the cluster (And they're on a rotation) [the original issue] im still slightly confused as to why

--target

is behaving in this way. As there are easily a dozen resources directly related to the provider that

pulumi

does not seem to care about when i use

--target

seems very odd that some distantly connected resource (by way of an arn referenced in an IAM policy) is marked for deletion, just because its not part of the

--target

chain IMO, the solve here is this epic, which I think allows dynamic provider credentials, but in the meantime Im solving symptoms

i think

refresh

would always break for this stack

If all this stack does it to make an RDS instance and create however many sets of admin credentials you need, it's fine if you're destroying and re-creating the admin credentials each time.