-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
r/aws_s3_bucket: support SSE-KMS replication configuration #2625
r/aws_s3_bucket: support SSE-KMS replication configuration #2625
Conversation
61b9b4d
to
bc018da
Compare
bc018da
to
55a00de
Compare
Glad to see a release with #2472. This one would have made a nice pairing (and it still does)! |
We'd also love to see this coming soon. |
@radeksimko Any chance this can make the 1.8.0 milestone? (Or is that one full up? 🙏) |
@jen20 @radeksimko any hope here? |
can haz merge? |
@modax Looks like you might have to take another pass here. Thanks for owning this! |
@modax: looks like this has conflicts now |
Looks like there are some conflicts. If we get the conflicts resolved, can we get this merged? |
55a00de
to
5696b4a
Compare
Given that we are deep with TypeSets here in Destination with a dynamic key (i.e. destination bucket name), we cannot use simple resource.TestCheckResourceAttr anymore due to hard to predict set hash. Therefore use S3 API object matching instead (for replication rules). This iead was stolen from testAccCheckAWSS3BucketWebsiteRoutingRules.
5696b4a
to
2b42802
Compare
Fixed conflicts (removed two commits addressing other related problems that already been fixed in master), reran acc tests. However, it is really unfortunate that PR merging cycle takes such a long time... |
2b42802
to
2c8906e
Compare
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.
hey @modax
Thanks for this PR (and rebasing it) - apologies for the delayed review here!
I've taken a look through and raised one comment around the hash function which needs @radeksimko or @bflad to confirm is ok, but this otherwise LGTM 👍 I'll kick off the test suite now to confirm the tests are still good after the rebase
Thanks!
@@ -2086,6 +2154,12 @@ func rulesHash(v interface{}) int { | |||
if v, ok := m["status"]; ok { | |||
buf.WriteString(fmt.Sprintf("%s-", v.(string))) | |||
} | |||
if v, ok := m["destination"].(*schema.Set); ok && v.Len() > 0 { | |||
buf.WriteString(fmt.Sprintf("%d-", destinationHash(v.List()[0]))) | |||
} |
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.
Given this is adding an existing field to the hashcode function - this will appear as a diff to existing resources, I believe that should be fine, but @radeksimko / @bflad can confirm for sure
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.
In that case I think we should add state migration, so the diff doesn't appear for existing users who just upgraded and not use any new functionality.
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.
hi, @radeksimko,
I have just confirmed that neither of these:
- terraform apply
- terraform apply -refresh=false
- terraform refresh
report any changes after provider upgrade. Rule hash value changes in the state file after all of them though. Frankly, I have also expected 2) to report changes but for some reason it does not happen (must be related to how set hash is compared probably, i.e. always upfront or something).
Here is the tf code if you want to test yourself: https://gist.github.com/modax/9e13db22565ab2f1a26821e5ee5995e5
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.
confirmed that scenario ^ - LGTM 👍
This was done in the spirit of current testAccCheckAWSS3BucketExistsWithProvider. Previous provider for loop has been deprecated as of late.
@tombuildsstuff Thanks for review. Sorry for the late change, but I've just realized that my Hopefully this does not delay merge...
|
This has been released in version 1.10.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. |
This seriously might make my quarter. Thank you @modax for getting this in!! |
Oh man, this has me super bummed. I thought that this was exactly what I needed, but it turns out I also need the https://docs.aws.amazon.com/AmazonS3/latest/API/RESTBucketPUTreplication.html |
+1 for #3575 to get this working for cross-account replication, too |
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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
Fixes #2200, #2226
It would be great to get this merged soon. Thanks!