-
Notifications
You must be signed in to change notification settings - Fork 159
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
DynamoDB GSI minor autoscaling update in AWS is interpreted by Pulumi as GSIs requiring major changes #2856
Comments
@t0yv0 as our expert in all things diffs - do you feel it's a Pulumi-side issue? Any related issues in the bridge? TF provider does seem to mark it as TypeSet, so I'd naively expect the diff to be set-based https://github.com/hashicorp/terraform-provider-aws/blob/main/internal/service/dynamodb/table.go#L158. |
I'll take a closer look. Started pulumi/pulumi-terraform-bridge#1417 tracking issue, I've seen at least one more issue with sets affecting diff results, could be related. |
Thanks @mikhailshilkov @t0yv0 |
Thank you @chrishoward, I think we are good for now. Adding this to our planning backlog. |
@mikhailshilkov Curious what the progress on this is please, just so I can prioritise work accordingly internally in my team (ie. wait for the fix if it's coming soon, or find a workaround if it's a long way off). Thanks |
@mikhailshilkov @t0yv0 Curious if there has been progress on this please? All good if not, just want to know so our team can decide how to move forward with the issue. Thanks in advance |
Hi @chrishoward I have been going through set handling in bridged providers recently and I think I have some suggestions here, although I have not yet delved deeper into reproducing the issue with your particular setups. There are two levels to the issue, semantic level and presentation level. It appears that current Pulumi behavior is reasonable as to what it is actually doing, and it will be difficult to change that, however we do have an opportunity to make the presentation more intuitive. IN terms of moving forward for your team/workaround - the Semantics section is most relevant. SemanticsIt appears that autoscaling and refresh make your state inconsistent with your program, like this: sequenceDiagram
participant Autoscaling
participant Cloud
participant State
participant Program
Autoscaling->>Cloud: readCapacity := 54
Cloud->>State: pulumi refresh sets readCapacity := 54
Program->>State: pulumi up sets readCapacity := 50
To accept the readCapacity value of 54 you need to edit the Pulumi program as there is no command that does that. There is Perhaps ignoreChanges can be a useful workaround to suppress visible diffs in this case while still doing PresentationThe diffs appear to be reordering elements in a list. We could possibly do better here, though it is not an easy fix. TF has a native concept of sets with customizable identity while Pulumi does not. As a result, Pulumi represents TF sets as lists. Both TF and bridged Pulumi providers canonicalize the set element ordering so that simply reordering set elements or adding more than one identical element becomes a no-op change. Unfortunately the diff presentation is assuming these are lists and appears to show reordering them. |
I've filed pulumi/pulumi-terraform-bridge#1755 as an interesting usability improvement we could undertake in the bridge. |
What happened?
Current Behaviour
pulumi refresh
and view the diff (before actually finishing the refresh), it shows the latest updated GSI moves to the top of the GSI array.pulumi refresh
diff) that in AWS thesectionIdIndex
GSIreadCapacity
was updated from 50 to 54. As a result in Pulumi it shows as moving to the top of the GSI array.pulumi refresh
so that the Pulumi state matches AWS state (both have abovereadCapacity
as 54). Then when I run apulumi preview
it suggests that the Pulumi program state that will get deployed will not only revert thereadCapacity
back to the base 50, but considers it an entirely new GSI due to the array order, and suggests deleting the old GSI and recreating a new one.Expected Behaviour
I would expect Pulumi to identify the GSIs using their index name or something like that, and therefore the refresh diff or the preview would suggest that only the read/write capacities will be out of sync or require changing, not the entire GSIs
Example
Our DynamoDB Table Resource
Our Application AutoScaling Resource Creator Function
Our Application AutoScaling Resource Creator Function being Invoked
Output of
pulumi about
Additional context
Other Similar Issues
Another user mentions this as 'Issue #2' in their Github issue: pulumi/pulumi-aws-native#989
Contributing
Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).
The text was updated successfully, but these errors were encountered: