This message was deleted.

Can you run

pulumi up --logtostderr -v=3

and paste the output? Sometimes that helps.

I was using -v=9, is 9 deeper than 3?

The highest logging is with

-v=9 --logtostderr --debug --logflow

- you should see raw HTTP logs if you are on 0.6.0

That’s much better thanks!

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.

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.

You should file an issue for that. I would love to see that.