https://pulumi.com logo
#typescript
Title
# typescript
p

prehistoric-account-60014

03/17/2021, 3:48 PM
What's the easiest way to guarantee that a resource will always recreate when running
pulumi up
? In this case it's a
pulumi.dynamic.Resource
and I tried always returning
{ changes: true }
from
diff
, but that didn't work.
c

clever-sunset-76585

03/17/2021, 4:50 PM
I tried always returning 
{ changes: true }
 from 
diff
, but that didn’t work.
In order to _re_create the resource, you should also return
deleteBeforeReplace: true
as your
diff()
result. As the name implies,
delete()
will be called, followed by
create()
for your dynamic resource.
p

prehistoric-account-60014

03/17/2021, 5:35 PM
I don't need it to be deleted before its replaced. It's just that if I run
pulumi up
and the arguments didn't change, Pulumi doesn't even call
diff
. I ended up fixing this by instead implementing it how
docker.Image
works which uploads to the registry in the constructor when
pulumi.runtime.isDryRun()
is
false
It's a bit weird because this resource is a deployment and we want it to deploy every time
pulumi up
is called even if none of the inputs to it change
c

clever-sunset-76585

03/17/2021, 5:37 PM
You could trick the change detection by introducing a change token as one of the inputs to the dynamic provider. The change token could be a timestamp or some other value that you control how it is set. By changing it, you could cause the diff to be invoked I think.
l

little-cartoon-10569

03/17/2021, 8:33 PM
Or you could make the name of the resource different each time? Add a new suffix or similar? Since Pulumi manages a desired state, it doesn't really map to simple imperative operations too well. If you want a new cloud resource each time, you probably want to create a new Pulumi resource too: an array, instead of a single object.
p

prehistoric-account-60014

03/17/2021, 10:02 PM
Yeah, I thought of adding the git commit sha to the deployment metadata, or I could use a hash of the files being uploaded... As for the imperative operations dichotomy, this is something I explored a bit over a year ago with Docker and it does seem Pulumi is ok with it. Think of the
docker.Image
resource. Every time
pulumi up
is run it pushed up a new image, which is immutable, even thought there's only 1 resource, not an array. Also, the images are never deleted event though, for example, `gcp.storage.BucketObject`s do get deleted when the resource is destroyed
In this case the deployments I'm making are immutable deployments so the Docker image analogy works well. Anyhow, I think I'm satisfied with either passing a timestamp or git commit sha to the metadata or just doing it in the constructor like
docker.Image
does. Thanks so much for you replies guys 🙂
2 Views