-
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
[PLACEHOLDER] Refactor StateChangeConf and StateRefreshFunc Logic into Internal Packages #12840
Comments
…creation to that timeout and add KMS Key deletion to internal waiter package Reference: #7646 Reference: #12840 The Terraform AWS Provider codebase contains many varied timeouts for handling IAM propagation retries. Here we introduce a shared constant for this amount of time. The choice of 2 minutes is based on that amount of time being: - Most widely used across resources - Based on lack of historical bug reports across those resources that implement that amount of time, most successful - Ensuring a reasonable user experience (not waiting too long) should there be an actual misconfiguration As an initial implementation of this IAM propagation timeout and further showing the potential waiter package refactoring, this fixes shorter IAM timeout implementations in the `aws_kms_key` and `aws_kms_external_key` resources, while also refactoring the pending deletion logic. This second change is designed as an inflection point for how we want to handle imports across multiple waiter packages, with the preference of this initial implementation to name the Go import of the outside service, `iamwaiter`, or generically SERVICEwaiter. If agreed, this will be added to the proposal and the refactoring documentation. NOTE: There is other `StateChangeConf` / `StateRefreshFunc` logic in these KMS resources, but this change is solely focused on highlighting the multiple import situation, and those will be handled later. Output from acceptance testing: ``` --- PASS: TestAccAWSKmsExternalKey_basic (19.53s) --- PASS: TestAccAWSKmsExternalKey_DeletionWindowInDays (31.61s) --- PASS: TestAccAWSKmsExternalKey_Description (32.11s) --- PASS: TestAccAWSKmsExternalKey_disappears (13.84s) --- PASS: TestAccAWSKmsExternalKey_Enabled (312.55s) --- PASS: TestAccAWSKmsExternalKey_KeyMaterialBase64 (104.29s) --- PASS: TestAccAWSKmsExternalKey_Policy (33.78s) --- PASS: TestAccAWSKmsExternalKey_Tags (43.70s) --- PASS: TestAccAWSKmsExternalKey_ValidTo (165.77s) --- PASS: TestAccAWSKmsKey_asymmetricKey (18.20s) --- PASS: TestAccAWSKmsKey_basic (21.13s) --- PASS: TestAccAWSKmsKey_disappears (13.92s) --- PASS: TestAccAWSKmsKey_isEnabled (236.91s) --- PASS: TestAccAWSKmsKey_policy (35.34s) --- PASS: TestAccAWSKmsKey_Policy_IamRole (34.14s) --- PASS: TestAccAWSKmsKey_Policy_IamServiceLinkedRole (44.80s) --- PASS: TestAccAWSKmsKey_tags (34.65s) ```
…creation to that timeout and add KMS Key deletion to internal waiter package (#12863) Reference: #7646 Reference: #12840 The Terraform AWS Provider codebase contains many varied timeouts for handling IAM propagation retries. Here we introduce a shared constant for this amount of time. The choice of 2 minutes is based on that amount of time being: - Most widely used across resources - Based on lack of historical bug reports across those resources that implement that amount of time, most successful - Ensuring a reasonable user experience (not waiting too long) should there be an actual misconfiguration As an initial implementation of this IAM propagation timeout and further showing the potential waiter package refactoring, this fixes shorter IAM timeout implementations in the `aws_kms_key` and `aws_kms_external_key` resources, while also refactoring the pending deletion logic. This second change is designed as an inflection point for how we want to handle imports across multiple waiter packages, with the preference of this initial implementation to name the Go import of the outside service, `iamwaiter`, or generically SERVICEwaiter. If agreed, this will be added to the proposal and the refactoring documentation. NOTE: There is other `StateChangeConf` / `StateRefreshFunc` logic in these KMS resources, but this change is solely focused on highlighting the multiple import situation, and those will be handled later. Output from acceptance testing: ``` --- PASS: TestAccAWSKmsExternalKey_basic (19.53s) --- PASS: TestAccAWSKmsExternalKey_DeletionWindowInDays (31.61s) --- PASS: TestAccAWSKmsExternalKey_Description (32.11s) --- PASS: TestAccAWSKmsExternalKey_disappears (13.84s) --- PASS: TestAccAWSKmsExternalKey_Enabled (312.55s) --- PASS: TestAccAWSKmsExternalKey_KeyMaterialBase64 (104.29s) --- PASS: TestAccAWSKmsExternalKey_Policy (33.78s) --- PASS: TestAccAWSKmsExternalKey_Tags (43.70s) --- PASS: TestAccAWSKmsExternalKey_ValidTo (165.77s) --- PASS: TestAccAWSKmsKey_asymmetricKey (18.20s) --- PASS: TestAccAWSKmsKey_basic (21.13s) --- PASS: TestAccAWSKmsKey_disappears (13.92s) --- PASS: TestAccAWSKmsKey_isEnabled (236.91s) --- PASS: TestAccAWSKmsKey_policy (35.34s) --- PASS: TestAccAWSKmsKey_Policy_IamRole (34.14s) --- PASS: TestAccAWSKmsKey_Policy_IamServiceLinkedRole (44.80s) --- PASS: TestAccAWSKmsKey_tags (34.65s) ```
Updated to include information about multiple Go imports based off #12863, e.g. iamwaiter "github.com/terraform-providers/terraform-provider-aws/aws/internal/service/iam/waiter"
"github.com/terraform-providers/terraform-provider-aws/aws/internal/service/kms/waiter" |
…creation to that timeout and add KMS Key deletion to internal waiter package (hashicorp#12863) Reference: hashicorp#7646 Reference: hashicorp#12840 The Terraform AWS Provider codebase contains many varied timeouts for handling IAM propagation retries. Here we introduce a shared constant for this amount of time. The choice of 2 minutes is based on that amount of time being: - Most widely used across resources - Based on lack of historical bug reports across those resources that implement that amount of time, most successful - Ensuring a reasonable user experience (not waiting too long) should there be an actual misconfiguration As an initial implementation of this IAM propagation timeout and further showing the potential waiter package refactoring, this fixes shorter IAM timeout implementations in the `aws_kms_key` and `aws_kms_external_key` resources, while also refactoring the pending deletion logic. This second change is designed as an inflection point for how we want to handle imports across multiple waiter packages, with the preference of this initial implementation to name the Go import of the outside service, `iamwaiter`, or generically SERVICEwaiter. If agreed, this will be added to the proposal and the refactoring documentation. NOTE: There is other `StateChangeConf` / `StateRefreshFunc` logic in these KMS resources, but this change is solely focused on highlighting the multiple import situation, and those will be handled later. Output from acceptance testing: ``` --- PASS: TestAccAWSKmsExternalKey_basic (19.53s) --- PASS: TestAccAWSKmsExternalKey_DeletionWindowInDays (31.61s) --- PASS: TestAccAWSKmsExternalKey_Description (32.11s) --- PASS: TestAccAWSKmsExternalKey_disappears (13.84s) --- PASS: TestAccAWSKmsExternalKey_Enabled (312.55s) --- PASS: TestAccAWSKmsExternalKey_KeyMaterialBase64 (104.29s) --- PASS: TestAccAWSKmsExternalKey_Policy (33.78s) --- PASS: TestAccAWSKmsExternalKey_Tags (43.70s) --- PASS: TestAccAWSKmsExternalKey_ValidTo (165.77s) --- PASS: TestAccAWSKmsKey_asymmetricKey (18.20s) --- PASS: TestAccAWSKmsKey_basic (21.13s) --- PASS: TestAccAWSKmsKey_disappears (13.92s) --- PASS: TestAccAWSKmsKey_isEnabled (236.91s) --- PASS: TestAccAWSKmsKey_policy (35.34s) --- PASS: TestAccAWSKmsKey_Policy_IamRole (34.14s) --- PASS: TestAccAWSKmsKey_Policy_IamServiceLinkedRole (44.80s) --- PASS: TestAccAWSKmsKey_tags (34.65s) ```
Interesting. |
I'm concerned about creating a whole separate service package structure when the resources should also be in service packages. Also, I'm concerned about the proliferation of directories, For an alternate proposal, see #19347. (Easier to view in tree view: https://github.com/hashicorp/terraform-provider-aws/tree/td-repackage) |
This functionality has been released in v3.64.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. Thank you! |
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. |
Community Note
Description
This issue is a placeholder for future provider design considerations.
The Terraform AWS Provider, from its inception within the shared Terraform codebase, has existed as a monolithic Go package (
aws
). All resource, acceptance testing, and shared logic has co-mingled in this single Go package mostly in an effort to simplify community development for those unfamiliar with Go language and Terraform provider framework programming. Fast forward a few years and a few hundred more Terraform resources, this single Go package approach introduces a few burdens:go-pls
) spend many additional computational cycles to recompile this large package, slowing some gains that those provideLuckily for operators using the released binary, these development tradeoffs are invisible, however we would like to improve the development experience as well to improve time to feature release. Since the Terraform AWS Provider codebase is not to be considered an upstream library (in implementation consideration or versioning), we can freely adjust the codebase without those concerns. The main caveat to any refactoring work does however need to differentiate between acceptance testing and unit testing, whereas the Terraform Plugin SDK and associated tooling/handling would need notable development experience improvements before moving acceptance tests from the monolithic Go package.
In #12765, a proof of concept design for migrating some of the monolithic package code into its own per-AWS-service internal Go package was implemented. This internal package, which will likely be implemented with a few other common design patterns on a per-AWS-service level, has the following:
The
status.go
file holdingresource.StateRefreshFunc
, e.g.The
waiter.go
file holdingresource.StateChangeConf
and timeout constants (for those not needing customizable timeouts), e.g.This type of design can help with the following:
For resources implementing this logic, it becomes:
"github.com/terraform-providers/terraform-provider-aws/aws/internal/service/servicediscovery/waiter"
In cases where multiple service waiters or timeout constants are required (utilizing the IAM propagation timeout is very common), the preference is to have the current service Go import without an alias (effectively staying
waiter
), while prefixing the service name to other Go imports (genericallySERVICEwaiter
), e.g.Naming conventions:
resource.StateRefreshFunc
:{Thing}{StateField}
, e.g.OperationStatus
StateChangeConf
:{Thing}{Target}
, e.g.OperationSuccess
StateChangeConf
Timeout constants:{Thing}{Target}Timeout
e.g.OperationSuccessTimeout
{Description}Timeout
, e.g.PropagationTimeout
for IAM eventual consistencyAs another consideration, this effort could move us positively towards enabling
go-mnd
linting, if timeouts must be split into constants. This will reduce errors when attempting to update a timeout with multiple implementations.This refactoring would apply to all existing and future usage of
StateChangeConf
/StateRefreshFunc
until another design proposal supersedes this one.Definition of Done
StateChangeConf
/StateRefreshFunc
in the monolithicaws
package is statically analyzed and able to be manually reportedStateChangeConf
is migratedStateRefreshFunc
is migratedStateChangeConf
/StateRefreshFunc
in the monolithicaws
package is reported in CI for enforcementAffected Resource(s)
When the design work is completed and approved a list will be generated here.
The text was updated successfully, but these errors were encountered: