This change will allow aws_ebs_volume resources to be created with iops regardless of the volume type, whenever the volume type is not one of awstypes.VolumeType. This allows the provider to be used to create volumes in AWS-compatible backends that offer additional volume types not found in AWS. It also allows the aws_ebs_resource to support any potential new AWS volume types that would allow iops.
Relations
Closes #39838
References
Output from Acceptance Testing
I don't think it's possible to run acceptance tests for this since it would involve using a volume type that AWS doesn't consider valid. I didn't see any unit tests for aws_ebs_volume but if unit tests are needed for this I can add them.
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
For Submitters
Review the contribution guide relating to the type of change you are making to ensure all of the necessary steps have been taken.
For new resources and data sources, use skaff to generate scaffolding with comments detailing common expectations.
Whether or not the branch has been rebased will not impact prioritization, but doing so is always a welcome surprise.
Description
This change will allow
aws_ebs_volume
resources to be created withiops
regardless of the volume type, whenever the volume type is not one ofawstypes.VolumeType
. This allows the provider to be used to create volumes in AWS-compatible backends that offer additional volume types not found in AWS. It also allows theaws_ebs_resource
to support any potential new AWS volume types that would allowiops
.Relations
Closes #39838
References
Output from Acceptance Testing
I don't think it's possible to run acceptance tests for this since it would involve using a volume type that AWS doesn't consider valid. I didn't see any unit tests for
aws_ebs_volume
but if unit tests are needed for this I can add them.