-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
provider/aws: Fix DynamoDB issues about GSIs indexes #13256
Conversation
@@ -162,8 +162,6 @@ func resourceAwsDynamoDbTable() *schema.Resource { | |||
var buf bytes.Buffer | |||
m := v.(map[string]interface{}) | |||
buf.WriteString(fmt.Sprintf("%s-", m["name"].(string))) | |||
buf.WriteString(fmt.Sprintf("%d-", m["write_capacity"].(int))) | |||
buf.WriteString(fmt.Sprintf("%d-", m["read_capacity"].(int))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This solves the secondary issue and is needed for the first one.
for _, updatedgsidata := range gsiSet.List() { | ||
updates := []*dynamodb.GlobalSecondaryIndexUpdate{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the main point solving the first issue.
When having multiple GSIs, updates was storing the new GSI along with the n-1 one.
On the first iteration, it was storing the GSI as an update, and launching an update for the first index.
On the second iteration, it was storing the second GSI along with the previous GSI, and launching a new update made of both the N & N-1 updates.
As the N-1 was already being updated, the N couldn't be updated too.
Hey @Ninir – can you confirm that we don't need a state migration here? |
4c495f5
to
40fdc7d
Compare
40fdc7d
to
df8047b
Compare
|
||
if err := waitForGSIToBeActive(d.Id(), gsiName, meta); err != nil { | ||
return errwrap.Wrapf("Error waiting for Dynamo DB GSI to be active: {{err}}", err) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fixes an acceptance test issue where GSI were being updated, but a delete operation was happening before the update was finished.
As Indexes may take time to be updated, this ensures that the read /delete operation is made on updated data.
Hi @catsby A state migration was indeed required, and after some internal discussions with you & @apparentlymart, I ended up removing the Played a bit with it and it's all OK on the migration part. Ready on my side! Thanks for all the advices! 👍 |
Ran the tests:
Thanks! |
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. |
Description
This fixes 2 DynamoDB issues about GSI indexes. The first one is represented by the first two linked issues and is about the update of multiple GSIs.
The second one is about a diff that was really big. In fact, the
Set
attribute on theglobal_secondary_indexes
was using the read/write capacity. When this capacity was changed on the table, it has to be changed on indexes also, which generates the diff.Couldn't do separate PRs for that, since the second one was impacting the resolution of the first one with this error:
I also cleaned & normalized acc tests.
Related issues
Tests