Closed manwithaplandy closed 4 months ago
@manwithaplandy Sorry to let you run into this issue. From the log, it seems the auth works fine for the aztfexport
side, but something goes wrong at the provider side. Did you have environment variable exported (e.g. ARM_XXX
) that is conflicts with your Azure CLI setting?
To better understand what's happening in the provider side, could you re-run your command, with the following env vars exported:
TF_LOG_PATH
: An absolute path to where to store the log fileTF_LOG
: Set it to DEBUG
And share the log here.
I realize I forgot to include it in the original issue, but the environment is WSL Ubuntu 20.04 running on Windows 11.
To answer your questions, no, I did not have any environment variables exported that conflict with the Azure CLI setting. Azure CLI is configured and authenticated correctly, but I tried with and without the --use-azure-cli-cred flag to make sure that was use. The Azure CLI part seems to be working just fine - it is getting all of the resource information. It's the actual import part that is failing.
I agree it's on the terraform side, but I don't think it's the provider itself. When the .tf file is generated, the cloud environment isn't set, so terraform is still making API calls to the commercial endpoints and not the usgovernment endpoints.
The line environment = "usgovernment"
would need to be added to the provider.tf to set it up to use the correct endpoints. I tried adding that line manually and setting aztfexport to just append the state file instead of replacing the files, but that didn't seem to resolve the issue - it still makes API calls to the commercial endpoints.
@manwithaplandy Currently, these auth related settings only affect the aztfexport
part, but not the provider. The provider is expected to be configured via its environment variables. So in your case, you shall set the env via ARM_ENVIRONMENT
.
The reason we didn't pass through the option for aztfexport
to the provider setting is that currently there are two providers supported: azapi
and azurerm
. Both settings are similar but have slightly nuances. Meanwhile, these settings are evolving in the long run. To ensure users have the most flexibility about the provider config, we suggest to use the env vars defined by each provider.
That worked! Thank you!
Maybe it's worth adding that to the README because I didn't see that documented anywhere. It's confusing that there is a flag to set your cloud environment as part of the aztfexport tool, but it doesn't actually work. Also, both the azapi and azurerm providers handle setting the cloud environment in the exact same way, either by setting the ARM_ENVIRONMENT variable or adding an environment block to the provider config, so I would think you could add the environment block to the provider config if the env flag is passed in.
Either way, I was able to use the tool successfully so I will mark this issue as closed.
@magodo I agree with @manwithaplandy here that we should update our docs/clarify if ARM_ENVIRONMENT can be used to change the environment as expected. Just a good issue to think about from a usability perspective.
@stemaMSFT to clarify, not that it CAN be used, but that it MUST be used for the tool to work properly in non-commercial Azure environments.
@manwithaplandy Can you please try the main
branch and confirm it solved your issue? Then I'll make a new release for this.
I am attempting to use this tool to import existing resources into Terraform from an Azure environment, but no matter what I do I am getting the following error message:
I have tried the following command:
aztfexport res --use-azure-cli-cred --log-level TRACE --log-path log.txt --env usgovernment -s xxxxxxxxx /subscriptions/xxxxxxxxxxx/resourceGroups/xxxxxxxxx/providers/Microsoft.MachineLearningServices/workspaces/xxxxxxx
but it gives me the above error every time.I have also tried using the rg import command:
aztfexport rg --log-level TRACE --log-path log.txt --env usgovernment xxxxxxxxxxxxx
and it gives me the above error for every single resource in the resource group, including the resource group itself.I have used the az cli to list the resources successfully.
All of these resources have public access disabled and are accessible via private endpoint on a vnet. My machine is on a network that can reach resources in the vnet via privatelink.
Below is the (sanitized) log from using the first command: