https://pulumi.com logo
Title
b

broad-helmet-79436

05/11/2021, 6:06 PM
Hi there! I just got burned on something that was entirely my own fault, but I feel like Pulumi could have handled better. Long story short, in a single
pulumi up
I tried to both 1. rename a resource using
aliases
2. make a change to that same resource which caused it to be
replace
d This failed with
pending_operations
in the state file because I ended up with two different resources with the same alias at the same time. I guess the GCP and Kubernetes providers perform a
replace
by first creating the new resource and then deleting the old one? If so, I believe this will hit any resource which has any
aliases
defined, i.e., you don’t necessarily have to rename the resource at the same time as replacing it. I tried reproducing it in a local stack using the
@pulumi/random
provider, but I think that one replaces resources by deleting the old resource before creating the new one. For what it’s worth, I managed to make Pulumi show me this kind-of-strange diff:
pulumi preview
Previewing update (dev):
     Type                            Name                           Plan        Info
     pulumi:pulumi:Stack             pulumi-alias-replace-test-dev
 +-  ├─ random:index:RandomPassword  something_else                 replace     [diff: ~length]
 +-  └─ random:index:RandomPassword  pw                             replace

Resources:
    +-1 to replace
    1 unchanged
Here I’ve renamed the resource
pw
to
something_else
, added an alias, and at the same time changed the
length
of the RandomPassword which requires a
replace
operation. Does this ring a bell with anyone and/or is it worth a GitHub issue even though I haven’t been able to reproduce it (yet)?
b

bored-oyster-3147

05/11/2021, 6:15 PM
AFAIK Pulumi will always do a
create, then delete
for a
replace
action unless you specify
deleteBeforeReplace: true
in the
ResourceOptions
for any given resource. Meaning the order this takes place is not determined by the provider. Unfortunately I can't speak to the specific issue with your alias change so hopefully someone else will chime in
b

broad-helmet-79436

05/11/2021, 9:33 PM
Huh, that’s weird that it failed for both a GCP service account and a Kubernetes secret but not for a RandomPassword then. Maybe my hypothesis is completely off 😄
b

bored-oyster-3147

05/11/2021, 9:52 PM
The difference might just a side effect of the fact that RandomPassword isn’t actually provisioning any cloud infrastructure?
b

broad-helmet-79436

05/12/2021, 9:50 AM
Possibly. Not sure why it should result in two different resources with the same alias though, if it’s guaranteed to delete the old resource before creating the new one