azurerm_signalr_service ignore unsupported features for plans

[drdamour]

if you toggle some of the "boolean" features of azurerm_signalr_service like EnableConnectivityLogs, EnableMessagingLogs from in the portal or through api, then terraform thinks it needs to set them back to null. It tries, and then they are still just false.

Similar if you set them to "false".

Problem is only SOME features are "boolean" so how could you know which you should make null equivalent to false?

it's fine enough to set the supported features to "False" explicit to get outta the endless plans, but for unsupported by TF features like EnableLiveTrace if you toggle them on and off..TF always wants to set them to null.

Can we change the resource to just ignore unsupported by TF features instead of trying to null them out every time and failing?

the way the features are setup...i don't think there is a way to ignore specific features using lifecycle.ignore_changes so i have to ignore all the features to make this go away..which stinks. I'm sure the idea of making features a map block isn't a good one...but it'd make ignoring more specific. perhaps there's a trick to ignoring a specific sub block based on a key value of sub block..but i don't know it.

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.0.7
on windows_amd64
+ provider registry.terraform.io/hashicorp/azuread v1.6.0
+ provider registry.terraform.io/hashicorp/azurerm v2.79.1
+ provider registry.terraform.io/hashicorp/null v3.1.0
+ provider registry.terraform.io/microsoft/azuredevops v0.1.7

Affected Resource(s)

• azurerm_signalr_service

Terraform Configuration Files

resource "azurerm_signalr_service" "example" {
  name                = "example"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  tags                = azurerm_resource_group.example.tags


  sku {
    name     = "standard"
    capacity = 1
  }

  features {
    flag  = "EnableConnectivityLogs"
    value = "False"
  }
}

Debug Output

Panic Output

Expected Behaviour

Actual Behaviour

Steps to Reproduce

1. terraform apply

Important Factoids

References

• Support for EnableLiveTrace feature in azurerm_signalr_service #11353 - suspect many of the thumbs here are actually about this issue

[FlipABit]

Looks like this is covered in #11353

[drdamour]

Looks like this is covered in #11353

Its not, tomorrow they can add FeatureY and well be right back in this boat even if #11353 is implemented. This issue is for the broader compatibility going forward

[tombuildsstuff]

hey @drdamour

Thanks for opening this issue.

Taking a look through here this is unfortunate due to the design of the API - when this was first implemented we were under the impression these were only for Beta features in the API which would be GA'd to defaults - unfortunately these remain present even after these features had GA'd.

As such unfortunately at this point in time the List syntax that's being used here isn't ideal, and in retrospect we likely should have used top-level fields for this (e.g. live_trace_enabled = true) - but doing so at this point in time would be a breaking configuration change. From our side this is something we'll consider doing for the next major release (3.0) which we'll be publishing more details about in the not-too-distant future, since that'll require updating configs to match the migration.

For the moment I'm going to assign this to the 3.0 milestone and we'll take a look at this when we get to that - as @FlipABit has mentioned support for EnableLiveTrace specifically is being tracked in #11353 - but we'll leave this open since it's tracking a different behavioural change to these resources.

Thanks!

[drdamour]

@tombuildsstuff no doubt the underlying structure is pretty quirky. there's no way to support both with deprecated? there was something similar to this in azuread homepage_url and they supported both SxS for a while with a deprecation warning

[katbyte]

Hey @drdamour - we've changed updated how we handle features in #14360 by moving them to properly validated and named top level fields and I think this should help with any confusion around them. As such I'm going to close this for now but do let us know if it hasn't helped! (note I believe there was a bug in last weeks release wrt signal R so you may need tow air till this weeks release ons Thursday to give it a try)

[github-actions]

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.