Service Bus Capacity 0 is not allowed

[ducas]

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

Terraform v0.11.7

• provider.azurerm v1.5.0

Affected Resource(s)

• azurerm_servicebus_namespace

Terraform Configuration Files

resource "azurerm_servicebus_namespace" "service_bus" {
  name                = "${var.servicebus_name}"
  location            = "${var.resource_group_location}"
  resource_group_name = "${var.resource_group_name}"
  sku                 = "${var.servicebus_sku}"
  capacity            = "${var.servicebus_capacity}"

  lifecycle {
    prevent_destroy = true
  }
}

resource_group_location="australia east"
resource_group_name="my-service-bus-group"
servicebus_name="my-great-service-bus"
servicebus_sku="standard"
servicebus_capacity=0

Expected Behavior

As this is a standard bus which does not allow for messaging units capacity, 0 should be allowed.

Actual Behavior

Error: azurerm_servicebus_namespace.service_bus: ServiceBus Namespace Capacity can only be 1, 2 or 4

Steps to Reproduce

1. terraform apply

Important Factoids

[WodansSon]

@tombuildsstuff 0 is not a supported value for capacity. I tried to create one with the API directly and passed a capacity of 0. When I checked the resource after creation Azure automatically sets the value to 1. We would have to get the API to change to support this scenario.

[ducas]

Thanks for the response @tombuildsstuff , but I don't think that's necessarily true...

While 0 is not supported as a capacity for a premium namespace, no value is supported for a standard/basic namespace. Therefore when you try to apply again with 1, terraform will recognise that as a change to capacity and plan to destroy and recreate. Conversely, when you do not provide this value with a premium namespace it will default to 1 and subsequent plans will have the refreshed value of 1 again requiring a destroy and create.

By supporting a 0 value the provider should then be able to determine whether the capacity is actually supported/required by the namespace type and either raise an error if not or simply default to whatever the API does.

[katbyte]

Hello @ducas,

When you create a service bus with the Standard SKU the capacity defaults to 1. I'm not sure why the provider currently doesn't let you set it on standard/basic (the API just sets it to 1) or force a new resource on its change. I played around and it "seems" to work.

Please correct me if I am wrong here, but it seems like the issue is if one creates a premium servicebus without specifying the capacity it defaults to 1. Then later on, if you change it to 2 or 4 it needlessly forces a new resource?

If thats the case I think a better solution would be to always allow capacity to be set, limit it to 1 unless the SKU is Premium, and no longer force a new resource on its change. How does that sounds to you?

[katbyte]

Hey @ducas,

1.7 was released today with the above changes included. I hope this solves the problem for you.

[ghost]

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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!