Support for EnableLiveTrace feature in azurerm_signalr_service

[bm77525-kr]

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

Description

Currently, manually enabling the "Enable Live Trace" feature for a terraform managed signalR resource outside of terraform (via the Azure portal) causes it to try and revert the change on the next plan/apply:

resource "azurerm_signalr_service" "signalr" {

        # (10 unchanged attributes hidden)


      - features {
          - flag  = "EnableLiveTrace" -> null
          - value = "False" -> null
        }

        # (5 unchanged blocks hidden)
    }

Reverting the change is expected, but it attempts to revert it to null, so no matter if it's enabled or disabled in the portal (value True or False), it always tries to set the feature to null. It doesn't appear to cause any issue in the apply, but is a minor annoyance in that there will always be a diff and attempted resource change Adding the EnableLiveTrace to the resource doesn't appear to be supported:

Error: expected features.1.flag to be one of [EnableMessagingLogs EnableConnectivityLogs ServiceMode], got EnableLiveTrace
│
│   on resources-functions.tf line 113, in resource "azurerm_signalr_service" "signalr":
│  113: resource "azurerm_signalr_service" "signalr" {

New or Affected Resource(s)

• azurerm_signalr_service

Potential Terraform Configuration

resource "azurerm_signalr_service" "signalr" {

...

      features {
          flag  = "EnableLiveTrace"
          value = "True"
      }

...

}

[trennepohl]

Basically it's missing an enum in the features validations and the azure-go-sdk for the api 2020-05-01
I've made a simple fix locally and got it to work as expected.
https://github.com/trennepohl/terraform-provider-azurerm/commit/86dcda4394ba5b1553ce6b5f8c28ac0ebe0c62d1

Problem is, it's a bit confusing where I should submit a PR to get this updated, there are 3 other repos mentioned in the this Readme https://github.com/Azure/azure-sdk-for-go/blob/master/CONTRIBUTING.md

The problem is really simple to fix, but I don't want to submit a plain string just to get it working.

[Tiduster]

Hi !
This issue is a bit annoying because on our instance, each time we apply, terraform detect some changes in the feature flags:

  # azurerm_signalr_service.this will be updated in-place
  ~ resource "azurerm_signalr_service" "this" {
        id                          = "/subscriptions/***
        name                        = "sigr-dev-cnto-indigo"
        tags                        = {}
        # (10 unchanged attributes hidden)


      - features {
          - flag  = "EnableLiveTrace" -> null
          - value = "False" -> null
        }

        # (5 unchanged blocks hidden)
    }

@trennepohl: As you said, to fix the issue you change azurerm/internal/services/signalr/signalr_service_resource.go
But the documentation you linked says:

These generated packages depend on the HTTP client implemented at Azure/go-autorest. Therefore when contributing, please make sure you do not change anything under the services directory.

Can someone point us in the right direction?

Much appreciated.

[trennepohl]

Sure, I even asked in the #azure-sdk-for-go channel in Slack.

looks like the right place to submit a fix would be https://github.com/Azure/azure-rest-api-specs/blob/master/specification/signalr/resource-manager/Microsoft.SignalRService/stable/2020-05-01/signalr.json

But as you can see Joel recommended opening an issue.

[daojah]

@trennepohl hello!

Your link above not working anymore - https://github.com/trennepohl/terraform-provider-azurerm/commit/86dcda4394ba5b1553ce6b5f8c28ac0ebe0c62d1

Could you please share how you fixed it?

[trennepohl]

@daojah sorry I deleted the fork as the real fix involves a bunch..

Please keep in mind that the solution below is not the best way to go, the best way to go would be a new version of the azure-go-sdk and a new provider version, but as mentioned in the comments above it depends from this file being updated.

However, if you want to have your own custom version of azure-sdk-for-go and terraform you can just add one more constant here

and then add the newly created constant to this function return here

Something like this did the trick for me (my own custom version of terraform and the azure-go-sdk)

const (
	// EnableConnectivityLogs ...
	EnableConnectivityLogs FeatureFlags = "EnableConnectivityLogs"
	// EnableMessagingLogs ...
	EnableMessagingLogs FeatureFlags = "EnableMessagingLogs"
	// ServiceMode ...
	ServiceMode FeatureFlags = "ServiceMode"
        //EnableLiveTrace
        EnableLiveTrace = "EnableLiveTrace"
)

// PossibleFeatureFlagsValues returns an array of possible values for the FeatureFlags const type.
func PossibleFeatureFlagsValues() []FeatureFlags {
	return []FeatureFlags{EnableConnectivityLogs, EnableMessagingLogs, ServiceMode, EnableLiveTrace}
}

[drdamour]

@thiagocaiubi did u open an issue for signalr.json?

[thiagocaiubi]

@thiagocaiubi did u open an issue for signalr.json?

Hey @drdamour, I think you meant @trennepohl. 👍

[joshjohanning]

Hi ! This issue is a bit annoying because on our instance, each time we apply, terraform detect some changes in the feature flags:

  # azurerm_signalr_service.this will be updated in-place
  ~ resource "azurerm_signalr_service" "this" {
        id                          = "/subscriptions/***
        name                        = "sigr-dev-cnto-indigo"
        tags                        = {}
        # (10 unchanged attributes hidden)


      - features {
          - flag  = "EnableLiveTrace" -> null
          - value = "False" -> null
        }

        # (5 unchanged blocks hidden)
    }

@Tiduster For the instance Azure SignalR service I created through the portal and imported into my Terraform state, I had the same issue as you, every time I ran a plan it tried to drop the EnableLiveTrace feature.

>       - features {
>           - flag  = "EnableLiveTrace" -> null
>           - value = "False" -> null
>         }

For the Azure SignalR resource I created via Terraform natively, it was not part of my subsequent plans.

My solution was to taint and re-create the resource that was originally created in the portal.

My terraform:

resource "azurerm_signalr_service" "example" {
  name                                 = "example"
  location                             = var.location
  resource_group_name                  = azurerm_resource_group.app.name

  sku = {
    name     = "Standard_S1"
    capacity = 1
  }

  cors = {
    allowed_origins = ["*"]
  }

  features = {
      flag  = "EnableConnectivityLogs"
      value = "True"
    },
    {
      flag  = "EnableMessagingLogs"
      value = "False"
    },
    {
      flag  = "ServiceMode"
      value = "Default"
    },

  tags = var.tags
}

Edit: Apparently don't taint and re-create the resource unless you want a bunch of random 503 errors (disguised as CORS errors) on your Azure SignalR service - give it a new name. After some time (like a half hour) the 503 state goes away, but I was impatient and just gave it a new name.

[drdamour]

yeah there's some secondary bug here where it defaults those to null, but the current state if ever touched (like you enabled then disabled something) will make it false..and terraform tries to go from false to null, but the azure rm api seems to just ignore the null and leave it as false. rather annoying

[github-actions]

This functionality has been released in v2.90.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]

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.