Skip to content
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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plan-Time Resource Uniqueness Errors #14394

Open
bflad opened this issue Jul 30, 2020 · 4 comments
Open

Plan-Time Resource Uniqueness Errors #14394

bflad opened this issue Jul 30, 2020 · 4 comments
Labels
enhancement Requests to existing resources that expand the functionality or scope. proposal Proposes new design or functionality. provider Pertains to the provider itself, rather than any interaction with AWS. upstream-terraform Addresses functionality related to the Terraform core binary.

Comments

@bflad
Copy link
Member

bflad commented Jul 30, 2020

Community Note

  • Please vote on this issue by adding a 馃憤 reaction to the original issue 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 issue followers and do not help prioritize the request

Description

In any sufficiently large Terraform environment, there is potential for multiple resources to be planned for creation that cannot be successfully applied due to API uniqueness constraints. Operators have repeatedly asked for enhancements to Terraform and Terraform AWS Provider to provide this type of validation at plan-time. This issue serves as a meta-enhancement request to collect community interest around this for prioritization and prevent further issue sprawl with individual resource requests that are harder to collectively prioritize as part of the same effort.

An example Terraform configuration that should generate one of these types of errors:

# Trivial example of overlapping resource management.
# Usually these issues are spread across many Terraform
# configuration files or modules. :)

resource "aws_backup_vault" "example1" {
  name = "example"
}

resource "aws_backup_vault" "example2" {
  name = "example"
}

Resource uniqueness constraints are almost exclusively resource type dependent and in the case of AWS service APIs, may include any number of the following as potential constraints:

  • Per AWS Partition
  • Per AWS Account
  • Per AWS Region
  • Per resource attribute (e.g. identifier or name)
  • Per parent resource attribute (e.g. one policy resource for a resource)

Some examples of these uniqueness constraints:

  • aws_backup_vault (1 name value per AWS Region per AWS Partition per AWS Account ID)
  • aws_dynamodb_table (1 name value per AWS Region per AWS Partition per AWS Account ID)
  • aws_ebs_default_kms_key (1 per AWS Region per AWS Partition per AWS Account ID)
  • aws_ebs_encryption_by_default (1 per AWS Region per AWS Partition per AWS Account ID)
  • aws_iam_account_alias (1 per AWS Partition per AWS Account ID)
  • aws_iam_account_password_policy (1 per AWS Partition per AWS Account ID)
  • aws_iam_group_policy (1 name value per group value per AWS Partition per AWS Account ID)
  • aws_iam_role_policy (1 name value per role value per AWS Partition per AWS Account ID)
  • aws_iam_user_policy (1 name value per user value per AWS Partition per AWS Account ID)
  • aws_s3_bucket (1 bucket value per AWS Partition)
  • aws_s3_bucket_notification (1 bucket value per AWS Partition)
  • aws_s3_bucket_policy (1 bucket value per AWS Partition)
  • aws_sns_topic (1 name value per AWS Region per AWS Partition per AWS Account ID)

These uniqueness constraints must be checked in various lifecycles of two conflicting resources including:

  • When none exist and both are being created
  • When one exists and one is being created/updated
  • When both exist and both are being updated/recreated

Only comparing resources in the new, expected Terraform state of any planning operation should cover these cases.

While a provider, such as the Terraform AWS Provider, could implement its own framework for handling this type of issue, it would require some additional amount effort due how Terraform core interoperates with provider resource planning today. Essentially, each provider instance would need to cache (in the meta) resource uniqueness keys for individual resources (per resource type) in their CustomizeDiff handling and return an error if the cached key already exists. Another consideration is that CustomizeDiff does not know about a resource's type, so this would need to be manually synthesized into the resource uniqueness handling.

A small effort could be done as a proof of concept implementation in the Terraform AWS Provider, however the Terraform Plugin SDK seems a much better fit to standardize the implementation into resource definitions and for standardizing the error handling. Given this, operators are encouraged to also 馃憤 the Terraform Plugin SDK issue below, if interested.

References

Related Terraform AWS Provider feature requests:

@ewbankkit
Copy link
Contributor

@bflad Do you see this issue also addressing cases like #15786, #10473 or #10930 where a resource is being renamed in code without the equivalent terraform state mv, causing resource deletion and creation (for the same underlying AWS resource) to occur concurrently?

@jorhett
Copy link

jorhett commented Apr 5, 2023

3 years now and all of those major issues linked to this and closed have no answers

@mcncl
Copy link

mcncl commented May 3, 2023

Keen on finding out the status of this too. We're looking at adding this feature in to our own provider and it doesn't look possible right now.

@jwieder
Copy link

jwieder commented Mar 20, 2024

This issue also impacts creation of aws_route resources. aws_route resources should be unique for combination of destination CIDR & rtbl ID. AWS API doesnt catch this, either, which can result in deletion of default routes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Requests to existing resources that expand the functionality or scope. proposal Proposes new design or functionality. provider Pertains to the provider itself, rather than any interaction with AWS. upstream-terraform Addresses functionality related to the Terraform core binary.
Projects
None yet
Development

No branches or pull requests

6 participants