New AzCore API Breaks Environment

[jahn-swob]

What happened?

Hello,

I was previously using v2.60.0 of the Azure Native plugin with Azure Government with success but recently decided decided to bump up to the latest v2.77.0 and noticed that all my CI builds were failing.

I started investigating and found that in the v2.71.0 release notes there is mention of a new AzCore backend for the API that has been enabled by default and it notes instructions to disable it to fall back to the previous implementation.
After finding that and disabling the new AzCore backend, my builds are working again.

It appears that the new AzCore API changes are not respecting the ARM_ENVIRONMENT / azure-native:environment settings as it is clearly dialing the Azure Commercial endpoints instead of the Government ones.

Example

1. Use an Azure Government environment
2. Specify azure-native:environment in the Pulumi config for the stack
3. pulumi up
   • explosions.

Output of pulumi about

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 @jahn-swob, apologies for this issue. Which of the authentication methods of the provider are you using in CI?

Edit: nevermind, I see the issue and it's independent of the auth method.

[jahn-swob]

Hi @jahn-swob, apologies for this issue. Which of the authentication methods of the provider are you using in CI?

Edit: nevermind, I see the issue and it's independent of the auth method.

Correct.
For the record, when testing I typically authenticate with az login but in CI I use a service principal.

[pulumi-bot]

This issue has been addressed in PR #3799 and shipped in release v2.78.0.

[jahn-swob]

Thanks for the quick support, however there still appears to be an issue.

Also using static names from the SDK may prove to be an issue, especially with the things like Azure Stack / Azure Local where the management API URL may be something other than the defined variables.

There has to be a way to grab these values from the instance manager or something similar to ensure the correct endpoint addresses are being used.

[jahn-swob]

@thomas11 ^

[thomas11]

#3802 is most likely the fix. Sorry for the extra breakage. Unfortunately, we don't have usgov (or china) test infrastructure at this point, so we're relying on unit tests here, but these SDK internals are sometimes hard to cover.

[pulumi-bot]

This issue has been addressed in PR #3802 and shipped in release v2.79.0.