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

app_configuration_key should detect the parent app_configuration has been deleted #14665

Closed
jwefers opened this issue Dec 20, 2021 · 2 comments
Closed

Comments

@jwefers
Copy link

jwefers commented Dec 20, 2021

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 "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform (and AzureRM Provider) Version

Terraform v1.1.1
on linux_amd64

  • provider registry.terraform.io/hashicorp/azurerm v2.89.0

Affected Resource(s)

  • azurerm_app_configuration_key
  • (azurerm_key_vault_secret)

Description

When deleting a parent resources outside of TF and TF declares also child resources under this parent, a newly run tf plan causes 404 errors for each child resources.
Top level resources are handled fine in that scenario, TF handles the external deletion and would rectify it by recreation of said resources. The same should, in general, hold true for child resources. Currently it does not.

This also affects key vault secrets and probably some other types, but those are the two i encounter regularly.

I know that in some cases, it cannot be distinguished between the resource being gone or firewall/permissions keep TF from refreshing. This should be influenced by provider feature flags.

Expected Behaviour

E.g. Azure App Config: I delete the whole Config Resource manually. I run TF plan and tf plan recognizes it as an external change and would recreate the App Config and all declared App Config Keys within.

Actual Behaviour

tf plan fails:

with azurerm_app_configuration_key.example,
│ on example.tf line xy, in resource "azurerm_app_configuration_key" "example":
│ xz: resource "azurerm_app_configuration_key" "example" {
│
│ configurationstores.ConfigurationStoresClient#Get: Failure responding to request: StatusCode=404 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="ResourceNotFound"
│ Message="The Resource 'Microsoft.AppConfiguration/configurationStores/example' under resource group 'example' was not found. For more details please go to
│ https://aka.ms/ARMResourceNotFoundFix"

Workaround

tf state rm for the child resources

@tombuildsstuff tombuildsstuff changed the title Deleting parent resources outside of tf causes plan to fail with 404 for child resources app_configuration_key should detect the parent app_configuration has been deleted Dec 20, 2021
@tombuildsstuff tombuildsstuff self-assigned this Mar 23, 2022
@tombuildsstuff tombuildsstuff added this to the v3.0.0 milestone Mar 23, 2022
@github-actions
Copy link

This functionality has been released in v3.0.0 of the Terraform 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!

@github-actions
Copy link

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 Apr 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants