-
Notifications
You must be signed in to change notification settings - Fork 98
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
Enhancement: error when resource exists in real infrastructure upon creation #1165
Comments
Hi @rickardl, Thank you for raising this issue. Apologies if you experienced any issues from this behaviour. This behaviour is done by design, and was chosen because APIC allows us to create/replace the existing configuration and from that moment directly manage it in state. When you would like to validate the changes that you want to apply you could first I am aware that some other providers trigger an error message if the object is already existing in real infrastructure during create, but would argue that there is no hard rule defining this behaviour. From terraform resources documentation, I see the following regarding creation of resources: "Create resources that exist in the configuration but are not associated with a real infrastructure object in the state." Furthermore in terraform state documentation, the following is mentioned: "Terraform expects that each remote object is bound to only one resource instance in the configuration. If a remote object is bound to multiple resource instances, the mapping from configuration to the remote object in the state becomes ambiguous, and Terraform may behave unexpectedly. Terraform can guarantee a one-to-one mapping when it creates objects and records their identities in the state. When importing objects created outside of Terraform, you must make sure that each distinct object is imported to only one resource instance." Our interpretation to this is that terraform "expects" each object to be unique in state but there is no definition that errors should be triggered upon creation of resources that are already existing in real infrastructure. I do not think we should change the existing behaviour, since this would break existing behaviour of the provider. Having stated that, I do think this could be a valuable addition to consider as an enhancement to the provider configuration, where a flag could be set to validate if a DN is already existing in the real infrastructure and would error when it is existing. Would that be an option that could work for you? |
aci_user_security_domain
Resources with Identical Names and DNs Lead to Inconsistent Terraform State Management
Hi @akinross, I truly appreciate the comprehensive explanation and the rationale behind the current design choice. Understanding that this behavior is intentionally designed and takes into consideration APIC's capabilities, provides significant clarity. However, I'd like to emphasize our primary concern regarding the potential catastrophic outcomes stemming from the unintentional deletion of remote resources. Such outcomes may not be anticipated by users, which is troubling. Although Terraform's documentation doesn't explicitly require error messages for pre-existing objects in the real infrastructure, I believe the principle of least surprise should be a cornerstone of our design philosophy. Users generally expect that their actions within a declarative configuration framework should not inadvertently lead to destructive consequences unless explicitly intended. Consider the following scenario: An end-user creates two resources:
These resources, both tracking the same remote resource However, when one resource is deleted:
It results in the removal of the remote resource tracked under Our configuration then only has
Upon the next application, terraform will prompt for In a complex infrastructure setup, this could trigger a domino effect, impacting other interconnected resources. This scenario highlights the need for a design approach that minimizes unexpected and potentially disruptive outcomes, something we'd be happy to contribute towards, both in design and implementation. Let me know your thoughts, our organization is large nordic customer and this has raised some barrier for us to adopt. |
Hi @rickardl, let me discuss this internally with the team. Do you mind sharing me the customer name, via email (akinross@cisco.com) I will get back to you early next week. |
Absolutely I sent you an email, enjoy the weekend! |
Is it possible to detect and warn about when multiple Terraform resources manage the same ACI resource? I got hit by a similar issue where I used |
Hi @bardahlm, Thank you for the suggestion we will take it into consideration when we start working on this issue. Follow the issue thread for any updates. |
Community Note
Terraform Version
Terraform v1.6.6 on darwin_amd64
APIC version and APIC Platform
Affected Resource(s)
aci_user_security_domain
Terraform Configuration Files
Debug Output
N/A
Panic Output
N/A
Expected Behavior
Terraform should prevent the creation of two
aci_user_security_domain
resources with identical attributes (specifically name and local_user_dn) or properly handle the conflict by notifying the user that a resource with these parameters already exists.It should also not end up in a scenario, where the resources tracked by the provider creates a scenario here, removing one also deletes the other one.
The Terraform Cisco ACI and/or provider should either:
aci_user_security_domain
resources with the same name and local_user_dn, orActual Behavior
Terraform plans and attempts to create two
aci_user_security_domain
resources with the same name and local_user_dn, leading to an ambiguous state where it seems both are created, but actually, only one exists in ACI. Subsequent Terraform runs show inconsistent behavior regarding the creation and destruction of these resources.See the tracked ID's here
Steps to Reproduce
aci_user_security_domain
resources in your Terraform configuration with identical name andlocal_user_dn
attributes.terraform apply
to apply the configuration. Notice that Terraform will attempt to create both resources without indicating any conflict.aci_user_security_domain
resource definitions and re-runterraform apply
. Terraform will now attempt to delete the supposedly existing resource, leading to inconsistencies.aci_user_security_domain
resource to the Terraform configuration and run terraform apply again. Terraform will attempt to create the resource anew, despite it supposedly having existed before.Important Factoids
The behavior suggests a gap in the solutions handling of resource uniqueness and idempotency, particularly in how it interacts with the ACI API to check for existing resources before attempting to create new ones.
References
The text was updated successfully, but these errors were encountered: