Terraspace Plugin Azurerm - auto create backend resource group / storage account

Hi @tung

I would like to get some information regarding the auto_create config for auto creating the backend azure resource group and storage account for saving the tfstates.

My issue was I received an HTTPNotFound error when my Terraspace project was trying to create the backend resource group and the storage account.
I fixed my issue and I, unfortunately, forgot to save the output log when I got this error.
Anyway, I can explain how to reproduce my issue.

I use Terraspace for a couple of months now and I have not had any issues with it since I got a new Azure subscription to deploy new resources.

I got a fresh newly created Azure subscription.
I create my Azure Service Principal, I set the right permission
But when I run my terraspace project, I always got HTTPNotFound

Something similar to this output:

Built in .terraspace-cache/APP/dev/southeastasia/stacks/my_resource_group_stack
Current directory: .terraspace-cache/APP/dev/southeastasia/stacks/my_resource_group_stack
Resource Group myresourcegroup-backend-terraspace already exists
Creating Resource Group myresourcegroup-backend-terraspace...
.............<Net HTTPNotFound 0x.......>

First as you can see on the log, it’s weird, it said the resource group already exists and the line after it tries to create the resource group. Not a big deal, I guess the log is not in the proper order on the stdout.
Anyway, the issue is right after saying that HTTPNotFound
which does not give me any clue except that something is wrong with creating the backend Resource Group then…

After digging coupling of hours to find the issue, I found that it was related to Azure Resource Provider which was not registered for “Microsoft.Storage” on that new Azure subscription.

So my question/issue is related the output from terraspace which saying creating the backend resource group, it seems that it’s not true? He is trying to check the “possibility” to create the storage account first before creating the backend resource group?
What I mean is, do you have a special order which is not what the output reflects?
Possible to add more explicit error message (I have already set debug on terraspace config config.logger.level = :debug)?
I have just guessed that something wrong with resource provider because I guess that if the resource provider needed is not registered then the Azure REST API won’t respond (hence HTTP Not Found).

The first time I saw the HTTPNotFound error, I checked the resource provider “Microsoft.Resources” (which is used for creating Resource Group on Azure) which is registered by default after creating a new Azure subscription, but I didn’t think about Microsoft.Storage one since the error message stopped on attempting to create the resource group backend (which is not created at the end)
I hope you see what I mean but you can easily reproduce my issue by unregistering your Microsoft.Storage resource provider on an Azure subscription and run a new terraspace project:


RE: I have just guessed that something wrong with resource provider because I guess that if the resource provider needed is not registered then the Azure REST API won’t respond (hence HTTP Not Found).

Looking at the resource_group_create.rb source code in the terraspace_plugin_azurerm library.

The resource_group.check_existence is handled by the armreset library that also had to write https://github.com/boltops-tools/armrest/blob/main/lib/armrest/services/resource_group.rb#L5

That eventually makes some net/http calls to the azure API https://github.com/boltops-tools/armrest/blob/c9e735551dee7d6d4b7999b1beb47c6b1cec122f/lib/armrest/api/base.rb#L27

I see logger.debug but don’t see logger.info which would be reported. Unsure where the <Net HTTPNotFound 0x.......> warning is coming from :thinking:

Maybe Azure API has changed some endpoints or relocated them and the net/http library follows to the new location and internally reports the warning so we see a <Net HTTPNotFound 0x.......>. That’s just a guess. Unsure. It looks like the warning is innocuous though.