Handle AWS keypairs which no longer exist #2005
Conversation
| @@ -65,6 +65,11 @@ func resourceAwsKeyPairRead(d *schema.ResourceData, meta interface{}) error { | |||
| } | |||
| resp, err := conn.DescribeKeyPairs(req) | |||
| if err != nil { | |||
| awsErr, ok := err.(aws.APIError) | |||
| if ok && awsErr.Code == "InvalidKeyPair.NotFound" { | |||
There was a problem hiding this comment.
What do you think about establishing a precedent to log a warning when we do d.SetId("") whenever we're in this NotFound situation? I imagine we don't do that in many places yet, or at all, but I feel like we should.
There was a problem hiding this comment.
I don't see why it would merit a warning. As I see it, this is just one among many ways the AWS state could diverge from the desired state as described by the configuration. If I'm concerned about monitoring unintended deviations of state, I can just run terraform plan (having not changed the configuration) and see all the deviations.
|
Can you please rebase on Basically, |
When refreshing a keypair, update state appropriately rather than crash if the keypair no longer exists on AWS. Likely fixes hashicorp#1851.
|
@catsby done. |
|
Thanks! I tacked on a single commit in #2032 to comply with the new error type, going with that. |
|
Oh, duh. I'm not dumb...just forgot to commit my changes before pushing them :) |
|
No worries, thanks again 😊 On Thursday, May 21, 2015, Phil Frost [email protected] wrote:
Clint |
|
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. |
ghost
locked and limited conversation to collaborators
When refreshing a keypair, update state appropriately rather than crash
if the keypair no longer exists on AWS.
Likely fixes #1851.