Hi, I’m running into errors using AzureNextGen dot...
# azure
b
Hi, I’m running into errors using AzureNextGen dotnet, it appears that Pulumi is receiving a blank error from ARM. I have 2 examples related to APIM, creating an ApiPolicy resource and creating a ProductApi resource. The output from Pulumi is the same in both scenarios:
error: autorest/azure: error response cannot be parsed: "" error: EOF
verbose logging doesn’t reveal anything extra
provider received rpc error Unknown: autorest/azure: error response cannot be parsed: "" error: EOF
Does anybody know a way to debug further. Is there somewhere in the Azure portal maybe that can shed some light on what’s failing?
t
Can you run
pulumi up --logtostderr -v=3
and paste the output? Sometimes that helps.
b
I was using -v=9, is 9 deeper than 3?
Level 3 doesn’t give much
t
The highest logging is with
-v=9 --logtostderr --debug --logflow
- you should see raw HTTP logs if you are on 0.6.0
🙂 1
b
That’s much better thanks!
Looks like the responses from MS are 404s
Looks like I’m using the wrong outputs to pass as inputs to another resource. Such as product.Id and api.Id for inputs ProductId and ApiId. Would probably be more intuitive if these inputs were called ProductName and ApiName so it’s more intuitive to pass product.Name and api.Name. This is already the case for ResourceGroupName that’s an input to most resources
The 2 resources that caught me out were ApiPolicy and ProductApi in ApiManagement
t
AzureNG pulls directly from the Azure API specs. Whatever it allows, Pulumi.AzureNextGen allows. If you need something else, you can use the Azure SDK or create something yourself that does a lookup.
b
It’s not a matter of not being able to do something, I fixed my code and now it works. It just wasn’t intuitive to pass a “Name” output from 1 resource to an “Id” input of another when there’s also an “Id” output on that resource. Now I know that all the Id outputs contain an entire path to the resource and the inputs generally just want the name. However the side effect of this simple user error was the above message that the error couldn’t be parsed. Not very helpful. The response from Azure was a 404 which lead me to look at the URL and see the encoded path where the product name looked like it should be. I guess a simple improvement would be for the Pulumi error parser to recognise a 404 response with no body and output that information as a build error, instead of noting the EOF. Including the ARM resource URL with the 404 message could help people identify their error.
t
You should file an issue for that. I would love to see that.
👍 2