supporting S3 providers that don't implement acceleration, payer or lock configuration

[mflorin]

Change Description

In order to support third party S3 providers that do not support acceleration, request payer or lock configuration when
managing buckets, we need to be able to skip those operations. For that, we've implemented three new attributes on the aws_s3_bucket resource:

• skip_acceleration_config
• skip_payer_config
• skip_lock_config

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for pull request followers and do not help prioritize the request

Closes #13726

Output from acceptance testing:

$ AWS_PROFILE=default AWS_DEFAULT_REGION=eu-central-1 make testacc TESTARGS='-run=TestAccAWSS3Bucket_SkipConfig'
==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test ./aws -v -count 1 -parallel 20 -run=TestAccAWSS3Bucket_SkipConfig -timeout 120m
=== RUN   TestAccAWSS3Bucket_SkipConfig
=== PAUSE TestAccAWSS3Bucket_SkipConfig
=== CONT  TestAccAWSS3Bucket_SkipConfig
--- PASS: TestAccAWSS3Bucket_SkipConfig (28.72s)
PASS
ok  	github.com/terraform-providers/terraform-provider-aws/aws	30.553s

[github-actions]

Welcome @mflorin 👋

It looks like this is your first Pull Request submission to the Terraform AWS Provider! If you haven’t already done so please make sure you have checked out our CONTRIBUTING guide and FAQ to make sure your contribution is adhering to best practice and has all the necessary elements in place for a successful approval.

Also take a look at our FAQ which details how we prioritize Pull Requests for inclusion.

Thanks again, and welcome to the community! 😃

[dabo-devconsole]

There are also providers which do not support versioning e.g. Strato HiDrive S3.
It would be great that also skip_versioning can be implemented.

[zhelding]

Pull request #21306 has significantly refactored the AWS Provider codebase. As a result, most PRs opened prior to the refactor now have merge conflicts that must be resolved before proceeding.

Specifically, PR #21306 relocated the code for all AWS resources and data sources from a single aws directory to a large number of separate directories in internal/service, each corresponding to a particular AWS service. This separation of code has also allowed for us to simplify the names of underlying functions -- while still avoiding namespace collisions.

We recognize that many pull requests have been open for some time without yet being addressed by our maintainers. Therefore, we want to make it clear that resolving these conflicts in no way affects the prioritization of a particular pull request. Once a pull request has been prioritized for review, the necessary changes will be made by a maintainer -- either directly or in collaboration with the pull request author.

For a more complete description of this refactor, including examples of how old filepaths and function names correspond to their new counterparts: please refer to issue #20000.

For a quick guide on how to amend your pull request to resolve the merge conflicts resulting from this refactor and bring it in line with our new code patterns: please refer to our Service Package Refactor Pull Request Guide.

[mneverov]

@mflorin i tried to resolve the conflicts after the refactoring and I think it is easier to reimplement this using the new code structure. Do you plan to do that or may i take a stab at it?

[mflorin]

@mflorin i tried to resolve the conflicts after the refactoring and I think it is easier to reimplement this using the new code structure. Do you plan to do that or may i take a stab at it?

@mneverov - Hello, I don't think I'll be able to do that in the near future. Feel free to give it a try. Thanks :)

[anGie44]

Hi @mflorin @mneverov 👋 , thank you for raising this PR. Are these skip conditions implemented to avoid the specific NotImplemented or XNotImplemented error returned from the aws_s3_bucket resource? If so, it's possible the PR, #23278, already skips errors for some of the arguments

[rslinckx]

@anGie44 the referenced PR is indeed solving those use cases. I still have one issue with bucket tags which are apparently not implemented in my flavor of S3:

│ Error: error listing tags for S3 Bucket (xxxxxx): NotImplemented: A header you provided implies functionality that is not implemented.
│ 	status code: 501, request id: 8296f17fa1448f9570ff, host id: 8296f17fa1448f9570ff

I think the tags could have the same treatment and ignore NotImplemented responses ?

[anGie44]

Hi @rslinckx 👋 . Yes, looks like the GetBucketTagging call that takes place there could ignore that error as well. I've added the API method to the list here: #23291 (comment)

[MPV]

I'm using v4.6.0 and I'm still getting the below, so I suppose that #23278 hasn't fully fixed this yet?

aws_s3_bucket.mybucket: Creating...
╷
│ Error: error getting S3 Bucket acceleration configuration: XNotImplemented: The request you provided implies functionality that is not implemented.
│ 	status code: 501, request id: 1647961587738908, host id: 12596221

Would this PR solve it?

[anGie44]

Hi @MPV , just wanted to note here that the PR in reference #23278, accounts for the NotImplemented error, but not the unique XNotImplemented your are seeing. We ignored XNotImplented errors only when retrieving the bucket website.

[MPV]

Hi @MPV , just wanted to note here that the PR in reference #23278, accounts for the NotImplemented error, but not the unique XNotImplemented your are seeing. We ignored XNotImplented errors only when retrieving the bucket website.

@anGie44 Thanks for the clarification, that makes sense. Any thoughts on how to move forward with support for aforementioned XNotImplemented?

[github-actions]

I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.