Packer: Amazon EBS Builder leaves unencrypted snapshot behind in the AWS environment (cleanup behavior issue)

Created on 16 Apr 2019  ยท  11Comments  ยท  Source: hashicorp/packer

Packer Version 1.3.5

I am using the EBS builder to create an encrypted AMI. Everything provisions properly. The template creates a temporary EC2 instance from a base AMI with the boot volume.

After the provisioners successfully run the steps follow as below:

  1. Stop the source instance
  2. Create an unencrypted AMI from the source stopped instance/unencrypted snapshot
  3. Copy the unencrypted AMI using the provided non-default KMS key
  4. AMI is encrypted through the copy
  5. Unencrypted AMI is deregistered
  6. Encrypted AMI is tagged
  7. Encrypted snapshot is tagged
  8. Source instance is terminated
  9. No volumes to clean up (did not provision a non-root volume, but did set the launch_block_device_mappings)

The only resources left behind are the encrypted AMI, the encrypted snapshot, and the unencrypted snapshot from the unencrypted AMI which was used to create the encrypted AMI.

It is not readily apparent if this is a bug, intended behavior, or if I'm missing a way to configure for this temporary snapshot to be deleted. I believe it would make the most sense to delete this unencrypted snapshot through Packer as opposed to a separate process since Packer created this resource. However, if I need to resort to a separate process, I don't see how I can mark this temporary snapshot since it doesn't look like tags were created and the temporary instance ID doesn't seem to be preserved anywhere (at least not in the manifest).

image

https://gist.github.com/AndrewCi/c5414395305725d91182125bb0212d0f

bug buildeamazon

All 11 comments

Thanks for reporting. I'd say this is a bug. We should be deleting the unencrypted snapshot. I've reproduced and I'll take a look at fixing it now.

I've attached binaries of a patch that'll fix this to #7521; could you try it out and confirm for me that the proposed change works for you? (I've tested it with my own repro cases but I always like getting confirmation from the reporter)

I've attached binaries of a patch that'll fix this to #7521; could you try it out and confirm for me that the proposed change works for you? (I've tested it with my own repro cases but I always like getting confirmation from the reporter)

Which version did you update this from? Version 1.4.0 was not working for me (as per this issue https://github.com/hashicorp/packer/issues/7506). I've been using 1.3.5 as a result.

I updated it from master, which has already fixed that crash :)

Oops, was thinking of the wrong issue. Why do you need to run in CI with the debug flag?

Issue #7506 was impacting me with and without the debug flag.

Looks like Adrien's fix got us part way there; different error at least. I'll take a quick look and see if I can get you a build that fixes both.

Looks like you're running with on-error=ask? If you change that to on-error=abort or on-error=cleanup that should work around the bug in 7506 and allow you to test the binary I've provided on the PR to fix this issue. I'm still looking into why Adrien's fix didn't work for you.

Issue #7506 is still a problem regardless of the mode I run in. See my comment on that issue for an update.

Sounds good. I've merged the fix for this particular issue, and responded on the other one.

I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

frezbo picture frezbo  ยท  3Comments

paulcdejean picture paulcdejean  ยท  3Comments

Tensho picture Tensho  ยท  3Comments

DanielBo picture DanielBo  ยท  3Comments

craigsimon picture craigsimon  ยท  3Comments