Packer: build -force should remove existing AWS AMI

[crypt1d]

According to the docs, -force should remove existing artifacts before building, however this seems to work for QEMU but not for amazon-ebs builder:

# packer build -force template.json
[...]
==> amazon-ebs: Error: name conflicts with an existing AMI: ami-0f160a63
Build 'amazon-ebs' errored: Error: name conflicts with an existing AMI: ami-0f160a63

[cbednarski]

Thanks for opening an issue. This is a bit tricky. With local files (vmware and virtual box) -force simply overwrites files in your working directory. In AWS, though, the AMI in question may already be used in an ASG or similar so destroying it is potentially problematic.

[crypt1d]

AFAIK, if you de-register an AMI, the instances that were deployed with it previously will still be functioning. Or are you referring to something else?
In any case, how is that any more destructive than with local images? Shouldn't the user decide if he wants to destroy his image/AMI?
For example, I had to write a whole wrapper around packer to address this issue. I query the AMI list and de-register the image before calling packer, because packer is unable to deal with it itself.

[phanect]

Same on Google Cloud Platform.

$ packer build -force packer.json
googlecompute output will be in this color.

==> googlecompute: Checking image does not exist...
==> googlecompute: Image IMAGE_NAME already exists
Build 'googlecompute' errored: Image IMAGE_NAME already exists

==> Some builds didn't complete successfully and had errors:
--> googlecompute: Image IMAGE_NAME already exists

==> Builds finished but no artifacts were created.

AFAIK such problem shouldn't happen on GCP, so it looks easier to fix.

[cbednarski]

Thanks for following up here. As @crypt1d mentioned initially the docs are correct and the behavior is not currently consistent with the spec.

[mwhooker]

This is implemented now in GCE.

We should set AMIConfig.AMIForceDeregister if common.PackerConfig.PackerForce is set.

[isberg]

The fix for the -force flag is not available for Packer v0.12.3 but grabbing binaries from https://releases.hashicorp.com/packer/1.0.0-rc1/ worked successfully.