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

azurerm_eventhub_namespace is incorrectly replaced in 3.25.0+ when used with default zone_redundant value in regions that support Availability Zones #18756

Closed
1 task done
noelbundick-msft opened this issue Oct 13, 2022 · 6 comments · Fixed by #19164
Labels

Comments

@noelbundick-msft
Copy link

noelbundick-msft commented Oct 13, 2022

Is there an existing issue for this?

  • I have searched the existing issues

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 Version

v1.3.2 linux_amd64

AzureRM Provider Version

3.26.0

Affected Resource(s)/Data Source(s)

azurerm_eventhub_namespace

Terraform Configuration Files

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      # version = "3.24.0"  # requires zone_redundant when using Premium SKU, so there is no problem
      version = "=3.26.0"   # Starting in 3.25.0 does not require zone_redundant, defaults to False
    }
  }
}

provider "azurerm" {
  features {}
}

variable "location" {
  type = string
  default = "westus3"
}

resource "azurerm_resource_group" "repro" {
  name     = "repro-eventhubs-premium"
  location = var.location
}

resource "azurerm_eventhub_namespace" "repro" {
  name                = "repro-eventhubs-premium"
  location            = azurerm_resource_group.repro.location
  resource_group_name = azurerm_resource_group.repro.name
  sku                 = "Premium"
  capacity            = 1

  # If you don't include, this, your namespace will be deleted if you are in a region with Availability Zones
  # zone_redundant      = true
}

Debug Output/Panic Output

n/a

Expected Behaviour

Per the docs: "zone_redundant is computed by api based on the availability zone in each region. User's input will be overridden. It will turn into a computed property in 4.0 provider."

Expected behavior:

  • On initial deployment: westus3 supports Availability Zones, so it should create a namespace with zone_redundant = true
  • On subsequent deployment, I expect the same behavior - that a terraform apply will return "No changes. Your infrastructure matches the configuration."

Actual Behaviour

  • Initial deployment was successful, with some interesting & relevant notes in the output. Note that zone_redundant=False in here in the output, but the actual resource is created with zone_redundant=True:
  # azurerm_eventhub_namespace.repro will be created
  + resource "azurerm_eventhub_namespace" "repro" {
      + auto_inflate_enabled                      = false
      + capacity                                  = 1
      + default_primary_connection_string         = (sensitive value)
      + default_primary_connection_string_alias   = (sensitive value)
      + default_primary_key                       = (sensitive value)
      + default_secondary_connection_string       = (sensitive value)
      + default_secondary_connection_string_alias = (sensitive value)
      + default_secondary_key                     = (sensitive value)
      + id                                        = (known after apply)
      + local_authentication_enabled              = true
      + location                                  = "westus3"
      + maximum_throughput_units                  = (known after apply)
      + minimum_tls_version                       = (known after apply)
      + name                                      = "repro-eventhubs-premium"
      + network_rulesets                          = (known after apply)
      + public_network_access_enabled             = true
      + resource_group_name                       = "repro-eventhubs-premium"
      + sku                                       = "Premium"
      + zone_redundant                            = false
    }
  • On subsequent deployment, with no changes to the provided Terraform configuration, a plan/apply generates the following. Note that zone_redundant detects a change, which will destroy the entire namespace:
  # azurerm_eventhub_namespace.repro must be replaced
-/+ resource "azurerm_eventhub_namespace" "repro" {
      ~ default_primary_connection_string         = (sensitive value)
      + default_primary_connection_string_alias   = (sensitive value)
      ~ default_primary_key                       = (sensitive value)
      ~ default_secondary_connection_string       = (sensitive value)
      + default_secondary_connection_string_alias = (sensitive value)
      ~ default_secondary_key                     = (sensitive value)
      ~ id                                        = "/subscriptions/ed535055-bb61-47c6-b2f1-f1d702537e94/resourceGroups/repro-eventhubs-premium/providers/Microsoft.EventHub/namespaces/repro-eventhubs-premium" -> (known after apply)
      ~ maximum_throughput_units                  = 0 -> (known after apply)
      ~ minimum_tls_version                       = "1.2" -> (known after apply)
        name                                      = "repro-eventhubs-premium"
      ~ network_rulesets                          = [
          - {
              - default_action                 = "Allow"
              - ip_rule                        = []
              - public_network_access_enabled  = true
              - trusted_service_access_enabled = false
              - virtual_network_rule           = []
            },
        ] -> (known after apply)
      - tags                                      = {} -> null
      ~ zone_redundant                            = true -> false # forces replacement
        # (7 unchanged attributes hidden)
    }

Steps to Reproduce

This behaves correctly in regions without Availability Zones. Ex:

# First deploy: OK
terraform apply -var 'location=northcentralus'

# Second deploy: OK
terraform apply -var 'location=northcentralus'

The behavior is different in regions that do support Availability Zones: Ex:

# First deploy: OK
terraform apply -var 'location=westus3'

# Second deploy: PROBLEM
terraform apply -var 'location=westus3'

Important Factoids

No response

References

The behavior of zone_redundant was changed in 3.25.0 (but not listed in the release notes), making it no longer a required property for deploying namespaces with the Premium SKU.

In <3.25.0, this is not a problem, because zone_redundant must always be specified (and must always be True)

Relevant PR is here: #18542

@xiaxyi
Copy link
Contributor

xiaxyi commented Oct 14, 2022

Thanks @noelbundick-msft for raising this issue, I'm afraid that we may not be able to force the zone_redundant property as users won't be able to create an EventHub namespace if the region being specified doesn't have the availability zone enabled. This property is computed by api according to the availability functionality in each region. from your config, I noticed that the zone_redundant was not included in your TF config neither?

Besides, we have some tips in the docs about fact that the user's input will be overridden by api, have you got a chance to confirm about it?

feel free to let me know if you have any other questions or concerns.

@noelbundick-msft
Copy link
Author

@xiaxyi It seems to work fine on first deployment

As far as I can tell - then it gets saved into Terraform state with the default value (False) rather than the computed value (True)

So on next run - it detects a change, thinks it needs to recreate the namespace, and if allowed to do so - will drop it

re: zone_redundant user input being overridden by api - that isn't the case in practice. If I add zone_redundant = True, it resolves the issue and azurerm will not drop my namespace

Did you run through the sample configuration and see different results?

@xiaxyi
Copy link
Contributor

xiaxyi commented Oct 17, 2022

Thanks @noelbundick-msft for the comment, so based on the practice, the zone_redundant feature was not specified explicitly in the TF config during the first deployment. Then the namespace was created with the availability zone set to false, right?

I'll try west us 3 and see how the property gets provisioned.

@noelbundick-msft
Copy link
Author

Right - zone_redundant was not specified explicitly in the TF config on first deployment, but the namespace was actually created in westus3 with zone_redundant=true

The planned value shows zone_redundant=false (shown in the plan above), and I think this is what gets saved in the state file

Running the same configuration a second time will detect that difference between planned (false) vs actual (true) and drop the namespace since zone_redundant is flagged with ForceNew: true

@xiaxyi
Copy link
Contributor

xiaxyi commented Nov 4, 2022

@noelbundick-msft , I confirmed with service team. for premium namespace, zone_redundant will be enabled by default if the region selected supports availability zone, but it's not the case for standard namespace which will have it turned off by default.

Have you tried to add the zone_redundant = true in tf config?

@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 Dec 16, 2022
favoretti pushed a commit to favoretti/terraform-provider-azurerm that referenced this issue Jan 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
3 participants