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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to have a dependency between 2 attributes? #1267

Closed
orgads opened this issue Oct 25, 2023 · 2 comments
Closed

Is it possible to have a dependency between 2 attributes? #1267

orgads opened this issue Oct 25, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@orgads
Copy link

orgads commented Oct 25, 2023

SDK version

2.10.1

Regarding hashicorp/terraform-provider-azurerm#13337 about azurerm_key_vault_secret.

When value is changed, this results in changes also to version and to id, but these changes are not detected until apply.

Is it possible to have a dependency to informs tf that if value is changed this will result in other fields changing in the target state (known after apply)? Notice that this does not create a new resource (the operation doesn't delete the previous secret and create a new one), it just creates a new version on the existing secret, which is reflected in its id.

Terraform Configuration Files

resource "azurerm_key_vault_secret" "test" {
  name = "test"
  value        = "foo"
  key_vault_id = azurerm_key_vault.main.id
}

Expected Behavior

Changing the value should detect that version and id will change on apply, and consider them as "known after apply".

Actual Behavior

They're considered unchanged in the plan, and on apply they have unexpected values. This leads to inconsistent plan on dependent resources that use the id, or at least a need to apply twice.

Steps to Reproduce

  1. terraform init
  2. terraform apply
  3. Change value to "bar"
  4. terraform apply

References

@bflad
Copy link
Member

bflad commented Nov 2, 2023

Hi @orgads 👋 Thank you for raising this.

Yes, it is possible to do this in terraform-plugin-sdk based provider code (and terraform-plugin-framework based provider code when the provider is migrated). The helper/schema.Resource can have a CustomizeDiff function which runs during the plan and notifies Terraform that the attribute value is unknown after apply. The helper/customdiff.ComputedIf() function is a helper for this exact use case.

For example, the terraform-provider-aws aws_ssm_parameter resource is coded where the version attribute is marked as unknown when the value attribute changes:

https://github.com/hashicorp/terraform-provider-aws/blob/8ffcc5d56801b13773e0894cfb8a148766a980ed/internal/service/ssm/parameter.go#L132-L134

If the attribute value after update is known upfront, then a custom CustomizeDiff function can be written that calls (helper/schema.ResourceDiff).SetNew() to notify Terraform in the plan of the updated value.

Hope this helps. Please note that general provider development questions should either be asked in the provider issue tracker so those provider maintainers can offer a tailored answer for their particular provider coding patterns or on HashiCorp Discuss where there are many more developers to answer. This issue tracker here is used for bug reports and feature requests with the terraform-plugin-sdk Go module. Thanks!

@bflad bflad closed this as not planned Won't fix, can't repro, duplicate, stale Nov 2, 2023
Copy link

github-actions bot commented Dec 3, 2023

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants