resource/aws_datasync_task: Remove BEST_EFFORT value from posix_permissions argument validation and documentation #10985
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ssions argument validation and documentation Reference: https://github.com/aws/aws-sdk-go/pull/2962/files#diff-75343d273fb0174cc5d3bc82469018b5L6419 Reference: #10955 The upstream AWS Go SDK in v1.25.39 update removes the available SDK constant. In testing the behavior against the current SDK which still has this constant and when `BEST_EFFORT` is provided as a value to the DataSync API, the API returns a validation error: ``` --- FAIL: TestAccAWSDataSyncTask_DefaultSyncOptions_PosixPermissions (233.01s) testing.go:635: Step 0 error: errors during apply: Error: error creating DataSync Task: ValidationException: 1 validation error detected: Value 'BEST_EFFORT' at 'options.posixPermissions' failed to satisfy constraint: Member must satisfy enum value set: [PRESERVE, NONE] status code: 400, request id: 1b101b77-f03f-4be2-b018-e2edf4088536 ``` This API behavior seems to indicate that even if existing Terraform configurations might contain this value, they are invalid now according to the API and must be updated regardless. If for some reason this old value is still valid for previously existing tasks, we can hardcode the `"BEST_EFFORT"` string into the validation if necessary.
bflad
added
upstream
ghost
added
needs-triage
1 task
bflad
removed
the
needs-triage
koikonom
approved these changes
Nov 25, 2019
|
This has been released in version 2.40.0 of the Terraform AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. For further feature requests or bug reports with this functionality, please create a new GitHub issue following the template for triage. 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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks! |
ghost
locked and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Community Note
Reference: https://github.com/aws/aws-sdk-go/pull/2962/files#diff-75343d273fb0174cc5d3bc82469018b5L6419
Reference: #10955
Reference: https://docs.aws.amazon.com/datasync/latest/userguide/API_Options.html#DataSync-Type-Options-PosixPermissions
Release note for CHANGELOG:
The upstream AWS Go SDK in v1.25.39 update removes the available SDK constant. In testing the behavior against the current SDK which still has this constant and when
BEST_EFFORTis provided as a value to the DataSync API, the API returns a validation error as seen by this adjusted acceptance test:This API behavior seems to indicate that even if existing Terraform configurations might contain this value, they are invalid now according to the API and must be updated regardless. If for some reason this old value is still valid for previously existing tasks, we can hardcode the
"BEST_EFFORT"string into the validation as necessary.