InvalidKeyPair.Duplicate

[zimbatm]

When targeting amazon-instance and amazon-ebs in the same build, one of both will fail because the temporary key pair has the same name:

==> amazon-instance: Creating temporary keypair: packer 52668615-9acb-0442-f0c5-341eaa209b8e
==> amazon-ebs: Creating temporary keypair: packer 52668615-9acb-0442-f0c5-341eaa209b8e
[snip]
Build 'amazon-ebs' errored: Error creating temporary keypair: Duplicate key found when creating keypair packer 52668615-9acb-0442-f0c5-341eaa209b8e (InvalidKeyPair.Duplicate)

[zimbatm]

One solution to work around this issue is to change one of the builder's undocumented temporary key_pair name:

"temporary_key_pair_name": "packer {{uuid}} ebs",

[zimbatm]

It's the same issue with the unique security group that's created. Something is preventing the UUIDs from being randomly unique.

[zimbatm]

==> amazon-ebs: Creating temporary keypair: packer 526688d9-9acb-0442-f0c5-341eaa209b8e ebs
==> amazon-instance: Creating temporary keypair: packer 526688d9-9acb-0442-f0c5-341eaa209b8e
==> virtualbox: Downloading or copying Guest additions checksums
    virtualbox: Downloading or copying: http://download.virtualbox.org/virtualbox/4.2.18/SHA256SUMS
==> virtualbox: Downloading or copying Guest additions
    virtualbox: Downloading or copying: http://download.virtualbox.org/virtualbox/4.2.18/VBoxGuestAdditions_4.2.18.iso
==> amazon-instance: Creating temporary security group for this instance...
==> amazon-ebs: Creating temporary security group for this instance...
==> amazon-instance: Authorizing SSH access on the temporary security group...
==> virtualbox: Downloading or copying ISO
    virtualbox: Downloading or copying: http://releases.ubuntu.com/12.04/ubuntu-12.04.3-server-amd64.iso
==> amazon-ebs: The security group 'packer 526688db-700e-0976-6cb5-0b02afd3a30c' already exists (InvalidGroup.Duplicate)

For some reason the UUID is the same for the same key for both amazon-ebs and amazon-instance but notice that the UUID is different between the keypair and security group.

[pearkes]

This looks to have been added in 697c91b. I take it you're running 0.3.10?

[zimbatm]

Yeah I should have specified that I'm using 0.3.10. See related PR for a fix

[patricklucas]

My issue #556 was closed as a dupe of this one, though it had the added point of interest that the conflicts I experienced were in totally separate builds that happened to start at the same time—there's no requirement that 'amazon-ebs' and 'amazon-instance' be built in the same run.

@mitchellh: I have had 12 builds fail due to this issue since I upgraded to 0.3.10 yesterday afternoon; do you think there could be a hotfix release soon, or should I roll back to 0.3.9?

[mwhooker]

@patricklucas Are you able to build from source? This should be fixed in HEAD, but I can't speak to a point release

[patricklucas]

@mwhooker Thanks for merging the change. I would prefer sticking to a release, but it's not a huge deal to roll back to an earlier release. (Though I would lose the two fixes I contributed for some problems we experienced <v0.3.10)

I am continuing to see failures due to #552 fairly consistently since we use Packer in an automated build system where multiple builds can be triggered simultaneously due to upstream changes. This means that v0.3.10 is an essentially unusable release for production purposes, and a point release I believe is warranted.

If possible, I'd rather not spend the time to roll back the package across our cluster, but if it's going to be longer than a day or so, I will do that to cut back on the error emails my team is getting due to the persistent failures.

[mitchellh]

@patricklucas Please roll back for now. I may backport the entropy fix. Sorry about that.

This is fixed in git.

[stagrlee]

I've been seeing this quite a bit today (version 0.7.5). Stuck or terminated old packer runs leave behind lots of keypairs in AWS. Cleaning them up seemed to help. Not sure if this is a new issue or not. I'm running a few different packer builds in a row and have been seeing this on the 2nd packer run.