What's some good practice on filtering AMI? I started without locking the image id, which causes the next run of Pulumi may filter a different image (due to new releases). Then I flipped to locking the image id. That lasted much longer, until today we found the image is now deprecated. It is easy to just change to a different image id. But the EC2 has service running there, which we don't want to touch. Any suggestion?

Yes. Another idea is to provide the AMI ID as a value in your project config, so you decide when to update the AMI.

Thanks! That would still have the problem where the AMI no longer exists. In the code, we have to get AMI (

ec2.get_ami

) first

Yep, you would need to do that. Something I've been meaning to try in one of my projects is to have a new project whose only job is to export the approved AMI, and a

pulumi up

would export the updated AMI ID as a stack reference. Any

pulumi up

on related projects would then get the updated AMI. This two-stage process is essentially an automated alternative to what we're currently doing: approving a new AMI is separate from choosing to update a stack.

Looks like

ignore_changes

may not work for us.

ec2.get_ami

requires

InvokeOptions

, which does not support

ignore_changes

😞

Yes, you would use ignore_changes on the AMI ID of the AMI you're deploying, not on the call to get_ami. That is a read-only call, so nothing changes 🙂

Ah right