Backwards compatibility for AWS roles #189
Conversation
ghost
added
the
|
Seems reasonable to me. One question/concern: since the values are being read into both versions of the fields, will Terraform show a diff on subsequent plans if it's only set on one or the other in the config? |
There was a problem hiding this comment.
I found that calls were failing before reaching the state migration code due to a different field type being expected by the schema.
Do you have an example? This doesn't sound right, the migration should be ran before any external calls or other Provider code ran, IIRC
| @@ -319,16 +393,27 @@ func awsAuthBackendRoleRead(d *schema.ResourceData, meta interface{}) error { | |||
| d.Set("role", role) | |||
| d.Set("auth_type", resp.Data["auth_type"]) | |||
|
|
|||
| // Read Vault's response into the currently supported version of these fields. | |||
| d.Set("bound_account_ids", resp.Data["bound_account_id"]) | |||
There was a problem hiding this comment.
When setting aggregate types (list, set, map), we need to check the error from d.Set to make sure the data was correctly saved to state:
|
@idubinskiy thanks for looking! Yes, I think in that version of the code that could have happened. I updated the code to closely match the guide, and it should now be good to go. |
|
@catsby thanks for linking that guide, it was so helpful! I updated the code to match the guide's recommendations and will use the guide as a model going forward. |
tyrannosaurus-becks
deleted the
add-backwards-compatibility-for-pr-153
branch
…ds-compatibility-for-pr-153 Backwards compatibility for AWS roles
Adds backwards compatibility for #153 .
Fixes #177 .
Rather than using a state migration, this PR adds fields of two types with different names - one plural as a list, and one singular as a string. That's because in testing, I found that calls were failing before reaching the state migration code due to a different field type being expected by the schema.