DiagnosticSetting creation fails with not registered to use microsoft.insights

[szesch]

What happened?

Creating a DiagnosticSetting is failing with error: autorest/azure: Service returned an error. Status=<nil> <nil>. The subscription '<REDACTED>' is not registered to use microsoft.insights.

My expectation is that the microsoft.insights would be automatically registered.

Example

_, err = insights.NewDiagnosticSetting(ctx, "diagnosticSetting", &insights.DiagnosticSettingArgs{
		ResourceUri:                 subscriptionResourceURI,
		LogAnalyticsDestinationType: pulumi.String("Dedicated"),
		WorkspaceId:                 logAnalytics.ID(),
		Logs: insights.LogSettingsArray{
			&insights.LogSettingsArgs{
				CategoryGroup: pulumi.String("allLogs"),
				Enabled:       pulumi.Bool(true),
			},
		},
	})

Output of pulumi about

Version      3.103.1
Go Version   go1.21.5
Go Compiler  gc

Plugins
NAME          VERSION
azure-native  2.51.0
azure-native  2.51.0
azure-native  2.47.1
azure-native  2.47.1
azure-native  2.47.1
azure-native  2.45.0
command       0.11.1
go            unknown

Host     
OS       ubuntu
Version  22.04
Arch     x86_64

This project is written in go: executable='/usr/lib/go-1.22/bin/go' version='go version go1.22.5 linux/amd64'

Dependencies:
NAME                                                              VERSION
github.com/pulumi/pulumi-azure-native-sdk/management/v2           2.45.0
github.com/pulumi/pulumi-azure-native-sdk/operationalinsights/v2  2.47.1
github.com/pulumi/pulumi-azure-native-sdk/resources/v2            2.47.1
github.com/pulumi/pulumi-azure-native-sdk/subscription/v2         2.47.1
github.com/pulumi/pulumi-azure-native-sdk/v2                      2.51.0
github.com/pulumi/pulumi-command/sdk                              0.11.1
github.com/pulumi/pulumi/sdk/v3                                   3.127.0

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[thomas11]

Hi @szesch, sorry you're running into this error. That's not expected to happen.

A few questions:

1. Are you able to create other Azure resources?
2. How are you authenticating to Azure, and how is the subscription id configured? Can you double-check that it's all lowercase?

There are also experience reports on the web saying that deregistering and re-registering the microsoft.insights provider helped, which would point to an Azure issue. You might try that via the portal or az provider.

[olafurnielsen]

This is common for newly created Azure Subscriptions – they don't have all resource providers registered by default. When you create resources via the Azure Portal they tend to auto register those providers when they are first created which is not the case when deploying via IaC.

You can register the provider via az cli:

# Make sure you have the right subscription activated:
az account set --subscription <subscription name or guid>
az provider register --namespace Microsoft.Insights --wait

Or via the portal by navigating to the relevant Subscription and under Settings -> Resource providers select the provider you want to register.

There's a Pulumi resource - providerhub.ProviderRegistration – for those registrations but I've never been able to get it to work:

status code 400, {"error":{"code":"InvalidSubscriptionIdForProviderNamespace","message":"The resource provider namespace 'microsoft.insights' is not a part of allowed resource provider namespaces list."}}

[thomas11]

Hi @szesch, it would be helpful if you could respond to my questions above! Also, does this error occur in all your attempts to use Microsoft.Insights?

This is not a typical issue users of this provider have, but we may have missed an edge case.

@olafurnielsen providerhub.ProviderRegistration is for a different purpose, it's for Azure's Resource Provider as a Service, i.e., register your own RP.

[olafurnielsen]

@thomas11 Ah I hadn't realized that :/ Is this functionality then not exposed in the API specs?

[thomas11]

@thomas11 Ah I hadn't realized that :/ Is this functionality then not exposed in the API specs?

It is exposed in the spec but in form of a POST endpoint, which we cannot support automatically because their semantics are very different from each other. We can add such an endpoint with some hand-written code. This is tracked in #1075.