#We are going to rule out that TFE server

1 messages · Page 1 of 1 (latest)

low yacht
#

env should work locally as well. Just set the variables in the same environment.

The provider is open source and provided as is. There is no formal support.

deft iris
#

Got it... yeah local ENV worked. To be honest, I think where we're at now is that customer hasn't correctly applied the "SetupAsService" custom role against the service principal they are using so that's the latest avenue and we'll see where that leads. Thanks for the guidance so far!

deft iris
#

Sounds like still a no go. The specific error hasn't changed though but we're done checking all the boxes as far as we know and since I can get it to work I still think it's specific to their environment somewhere (possible PrivateLink/Firewall/ExpressRoute stuff? Although not sure how)

It calls the netapp-cloudmanager provider, then just says "Still creating..." over and over and then after a couple of minutes max comes back with the 404 BearerAuthorizer error that in the docs claim permissions issue against Azure essentially if I have that right.

Where I'm confused though is why is it a 404, and why is it asking against the resource that hasn't been created yet-- the VM itself. That very well could be normal and just not something I'm understanding about the flow for sure.

Error: azure.BearerAuthorizer#WithAuthorization: Failed to refresh the Token for request to https://management.azure.com/subscriptions/[redacted]/resourcegroups/[redacted]/providers/Microsoft.Resources/deployments/[redacted]?api-version=2020-06-01: StatusCode=404 -- Original Error: adal: Refresh request failed. Status Code = '404'.

#

Since it's a valid reply, we think any networking has been ruled out

low yacht
#

You can enable Terraform logging using the TF_LOG environment variable. We have first to create an Azure VM. If this works, you should see the VM in the Azure management console. Though the 404 bearer error most likely indicates a failure to authenticate with Azure when creating the VM or a dependency.

#

Are they using a service principal?

#

Yes, the deployments shows the attempt to deploy the VM. Azure will retry several times on the Bearer error, so this is why it takes so long even though nothing happened.

deft iris
#

Yes they are using a service principal, we definitely never see an attempt to make a VM on the Azure side though

#

I did a few TF_LOG runs but not on their TFE server yet I’ll have them try that and see what that shows

deft iris
deft iris
#

Do you think this is anything of concern?

"authorizing azure from environment: <nil>"

deft iris
#

Looks like they got it working by adding auth VARs that started with "AZURE_" instead of "ARM_" does that sound right?

peak quarry
deft iris