Error destroying postgres server configuration value

matthewi commented 4 years ago

Here's the plan from the destroy:

module.db.azurerm_postgresql_configuration.EnableReplication will be destroyed
  - resource "azurerm_postgresql_configuration" "EnableReplication" {
      - id                  = "/subscriptions/.../resourceGroups/internal/providers/Microsoft.DBforPostgreSQL/servers/dev-staging-postgres/configurations/azure.replication_support" -> null
      - name                = "azure.replication_support" -> null
      - resource_group_name = "internal" -> null
      - server_name         = "dev-staging-postgres" -> null
      - value               = "logical" -> null
    }

Which generates this error:

Error: Code="InvalidConfigurationValue" Message="The value 'OFF' for configuration 'azure.replication_support' is not valid. The allowed values are 'REPLICA,LOGICAL'."

Versions:

Terraform v0.12.26
+ provider.azuread v0.10.0
+ provider.azurerm v2.15.0

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

Affected Resource(s)

azurerm_XXXXX

Terraform Configuration Files

Relevant resources:

resource "azurerm_postgresql_server" "postgres" {
  name                = var.server_name
  location            = data.azurerm_resource_group.rg.location
  resource_group_name = data.azurerm_resource_group.rg.name
  sku_name     = "${upper(var.sku_code)}_${local.sku_family}_${var.vcores}"
  storage_mb            = local.storage_mb
  backup_retention_days = var.backup_retention_days
  geo_redundant_backup_enabled = local.geo_redundant_backup
  auto_grow_enabled = true

  administrator_login          = var.db_user
  administrator_login_password = random_password.database_password.result
  version                      = "11"
  ssl_enforcement_enabled      = true
}

resource "azurerm_postgresql_configuration" "EnableReplication" {
  name = "azure.replication_support"
  resource_group_name = var.resource_group_name
  server_name = azurerm_postgresql_server.postgres.name
  value = "logical"
}

Debug Output

From the trace:

2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: [DEBUG] AzureRM Response for https://management.azure.com/subscriptions/.../resourceGroups/internal/providers/Microsoft.DBforPostgreSQL/servers/dev-staging-postgres/configurations/azure.replication_support?api-version=2017-12-01:
...
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: [DEBUG] AzureRM Response for https://management.azure.com/subscriptions/.../resourceGroups/internal/providers/Microsoft.DBforPostgreSQL/servers/dev-staging-postgres/configurations/azure.replication_support?api-version=2017-12-01:
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: HTTP/2.0 200 OK
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: Cache-Control: no-cache
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: Content-Type: application/json; charset=utf-8
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: Date: Wed, 01 Jul 2020 22:42:24 GMT
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: Expires: -1
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: Pragma: no-cache
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: Server: Microsoft-HTTPAPI/2.0
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: Strict-Transport-Security: max-age=31536000; includeSubDomains
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: Vary: Accept-Encoding
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: X-Content-Type-Options: nosniff
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: X-Ms-Correlation-Request-Id: dabee3b7-5e41-7880-2180-cce0c1c3ad03
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: X-Ms-Ratelimit-Remaining-Subscription-Reads: 11988
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: X-Ms-Request-Id: da92c79d-b6fa-460a-833d-b3e31bba5adc
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: X-Ms-Routing-Request-Id: CANADAEAST:20200701T224224Z:6b6f8663-e11e-4b4e-9a53-727930a76744
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5:
2020-07-01T17:42:24.936-0500 [DEBUG] plugin.terraform-provider-azurerm_v2.15.0_x5: {"properties":{"value":"logical","description":"Sets the level of replication support (Read Replicas). Any change requires restarting the server to take effect.","defaultValue":"OFF","dataType":"Enumeration","allowedValues":"OFF,REPLICA,LOGICAL","source":"user-override","isConfigPendingRestart":"False","isDynamicConfig":"False"},"id":"/subscriptions/.../resourceGroups/internal/providers/Microsoft.DBforPostgreSQL/servers/dev-staging-postgres/configurations/azure.replication_support","name":"azure.replication_support","type":"Microsoft.DBforPostgreSQL/servers/configurations"}

Panic Output

Expected Behavior

Terraform removed/reset the configuration value.

Actual Behavior

Produced a error.

Steps to Reproduce

terraform apply

Important Factoids

References

0000

matthewi commented 4 years ago

@tombuildsstuff Some further investigation shows that while OFF is a valid value and the default, transitioning to OFF from an enabled state is not allowed. The docs suggest resetting this is handled implicitly by manipulating the servers in replication: https://docs.microsoft.com/en-us/azure/postgresql/howto-read-replicas-portal

matthewi commented 4 years ago

This also means that you can't use terraform to destroy a server that has had replication enabled. You have to use azure directly and then reconcile your state.

yupwei68 commented 4 years ago

Hi @matthewi , thanks for opening this issue. Upstream microsoft service team ticket has opened: https://github.com/Azure/azure-rest-api-specs/issues/10037, please track it.

matthewi commented 4 years ago

In light of the response from Microsoft, I think this is the behavior we need to implement:

Transition to OFF should handle the exception for invalid transition and return a friendly error
Destroy would not be a valid operation for this configuration item
When destroying the server the configuration value belongs to, we need to exclude this configuration item from the DAG, since it is impossible to destroy the configuration before/independent of the server
According to the Azure docs, destroying a postgres server with replication enabled has some different behaviors depending on the deployed topology. I'm not sure how best we can handle this. We can attempt to enumerate the apparent 2-3 possibilities, but I have a feeling there may be a lot of edge cases. I think unpredictable behavior would be much worse than failing the operation.

Thoughts?

lalexl commented 4 years ago

@matthewi could you please advice ETA for the proposed fix?

opsaaspo commented 3 years ago

@matthewi I am also interested in the way of fixing.

jgreat commented 3 years ago

Ideally Azure would return the appropriate values for the database type, but the upstream ticket has stalled out. Is it feasible to put a workaround on the Terraform side? This issue makes a huge mess and requires manual state edits to clean up.

Or progress on the 2015 feature request for a "skip on destroy" in core Terraform would be amazing for these situations. https://github.com/hashicorp/terraform/issues/3874#issuecomment-161715361 https://github.com/hashicorp/terraform/issues/23547

matthewi commented 3 years ago

This isn't directly related to work right now so I'm not sure when I would get around to making a fix. Its basically a dead end IMO with MS (works as intended). Unless something has changed since I filed the original issue, I think what I outlined is probably what will be necessary. Unfortunately this deviates from how the rest of the items in the provider are handled. I was hoping for some input the maintainers/community on if this sort of special case would be acceptable.

On Thu, Feb 4, 2021 at 1:17 PM Jason Greathouse notifications@github.com wrote:

Ideally Azure would return the appropriate values for the database type, but the upstream ticket has stalled out. Is it feasible to put a workaround on the Terraform side? This issue makes a huge mess and requires manual state edits to clean up.

Or progress on the 2015 feature request for a "skip on destroy" in core Terraform would be amazing for these situations. hashicorp/terraform#3874 (comment) https://github.com/hashicorp/terraform/issues/3874#issuecomment-161715361 hashicorp/terraform#23547 https://github.com/hashicorp/terraform/issues/23547

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/terraform-providers/terraform-provider-azurerm/issues/7567#issuecomment-773544241, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALTSKVVJQ6RIRGQKAGOMLDS5LXFHANCNFSM4OO66PIQ .

tombuildsstuff commented 3 years ago

@matthewi as you've mentioned unfortunately this really needs to be fixed by Microsoft - I've just posted a comment looking for an update: https://github.com/Azure/azure-rest-api-specs/issues/10037#issuecomment-773911110

From Terraform's perspective whilst we could essentially do nothing when destroying this value, it seems logical that disabling read replicas in the remote api would disable read replicas - so I think it's worth waiting for Microsoft to respond here before determining how to proceed, apologies for the delay here.

Thanks!

Tomasz-Kluczkowski commented 2 years ago

Anybody has a workaround for this problem please?

msglueck commented 11 months ago

@Tomasz-Kluczkowski the workaround is to have your TF code deleting the resources... when you get the error about OFF go to Azure portal and delete the DB manually. Then run your TF code again and it deletes the few leftovers.

hashicorp / terraform-provider-azurerm