https://pulumi.com logo
#aws
Title
# aws
r

rich-whale-93740

01/17/2024, 11:56 PM
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?
Oh I guess
ignoreChanges
can be useful here https://www.pulumi.com/docs/concepts/options/ignorechanges/
l

little-cartoon-10569

01/18/2024, 12:00 AM
Yes. Another idea is to provide the AMI ID as a value in your project config, so you decide when to update the AMI.
r

rich-whale-93740

01/18/2024, 12:03 AM
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
l

little-cartoon-10569

01/18/2024, 12:05 AM
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.
And this allows us to update the AMI, update our dev stack, test etc., and if necessary roll back the AMI-exporting project before updating our prod stack.
r

rich-whale-93740

01/18/2024, 12:17 AM
Looks like
ignore_changes
may not work for us.
ec2.get_ami
requires
InvokeOptions
, which does not support
ignore_changes
😞
l

little-cartoon-10569

01/18/2024, 12:17 AM
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 🙂
r

rich-whale-93740

01/18/2024, 12:18 AM
Ah right