When `AZURE_SUBSCRIPTION_ID` is set, `AZURE_SUBSCRIPTION_ID` isn't saved in the environment

[weikanglim]

Repro:

1. cd <empty>
2. azd init -> Pick minimal
3. AZURE_SUBSCRIPTION_ID='<sub>' azd provision
4. azd env get-values

Expected:
AZURE_SUBSCRIPTION_ID should be saved

Actual:
AZURE_SUBSCRIPTION_ID is not saved

Example:

⋊> ~/r/p/minimal on main ⨯ azd env get-values                                                                   10:36:50
AZURE_ENV_NAME="weilim-min-dev-1"
⋊> ~/r/p/minimal on main ⨯ AZURE_SUBSCRIPTION_ID='faa080af-c1d8-40ad-9cce-e1a450ca5b57' azd provision           10:36:51

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time

? Please select an Azure location to use: 42. (US) East US 2 (eastus2)
  You can view detailed progress in the Azure Portal:
  https://portal.azure.com/#blade/HubsExtension/DeploymentDetailsBlade/overview/id/%2Fsubscriptions%2Ffaa080af-c1d8-40ad-9cce-e1a450ca5b57%2Fproviders%2FMicrosoft.Resources%2Fdeployments%2Fweilim-min-dev-1-1686850623

  (✓) Done: Resource group: rg-weilim-min-dev-1

SUCCESS: Your application was provisioned in Azure in 39 seconds.
You can view the resources created under the resource group rg-weilim-min-dev-1 in Azure Portal:
https://portal.azure.com/#@/resource/subscriptions/faa080af-c1d8-40ad-9cce-e1a450ca5b57/resourceGroups/rg-weilim-min-dev-1/overview
⋊> ~/r/p/minimal on main ⨯ azd env get-values                                                                   10:38:41
AZURE_ENV_NAME="weilim-min-dev-1"
AZURE_LOCATION="eastus2"

This seems to be because in prompter.go, EnsureEnv calls p.env.GetSubscriptionId(), to decide whether to prompt and save the value. The implementation relies of GetSubscriptionId relies on os.Env as a fallback, which skips prompting and saving.

[weikanglim]

Personally, this is once again a signal that our abstractions are wrong. env needs to expose the idea of "EnvFileVariables" or "Variables" and "OS Variables".

[vhvb1989]

I see this as an expected behavior.

os-env-vars applies to all azd-projects within the system
azd-env-vars are scoped by project.

If you want to see the sub-id within azd-env, you have to call azd env set SUB_ID foo to apply that value for the current project/workspace only.

Think about this like VSCode workspaces v/s global config. When you run a workspace, you are not expecting to get all of your global settings copied to the workspace, but you are expecting to use any global for your workspace.

We could make azd env get-values to find known values from os-env. I think that's what is missing here. But the output should tell what settings are for the project and which are global env-vars

[weikanglim]

My perspective is that azd provision should stamp the subscription on the environment after provisioning.

[vhvb1989]

My perspective is that azd provision should stamp the subscription on the environment after provisioning.

That's a good point. I don't think we have a concrete/solid definition for the functional behavior of azd in such cases. I see pros and cons on both sides:

Case #1 -> Persisting sub after provision:
Pros:

• The azd-env is fused to the sub where resources are and it is not affected anymore by changes to the os-env. That ensure an isolation of the azd-env as soon as it is provisioned.

Cons:

• The feature seems incomplete because the sub can be easily changed, either by running azd env set AZURE_SUBCRIPTION other-sub or manually updating the .env file
• Multiple azd-projects can't be managed by one only os-env, as each project becomes independent from os-env as soon as its provisioned.

Case #2 -> Persisting sub after provision:
Pros:

• Multitple azd-projects can be managed by one single os-env. Projects would just obey the os-env.

Cons:

• Easy to get into errors where updates to os-env would make the next provision to fail or produce other results not expected.

I don't have one strong opinion about what should be the functional expected behavior here. It looks like right now it is #2, but not really per design, but for coincidence. Let's make some official docs about the azd-env and its relation to os-env on every case

[weikanglim]

To be concrete on the implementation, which is to restore the regressed behavior prior to recent changes:

AZURE_SUBSCRIPTION_ID feeds the default value of the prompt. When the environment already has AZURE_SUBSCRIPTION_ID set, it is ignored. AZURE_SUBSCRIPTION_ID is always persisted in .env after provisioning.

On whether environments are strongly or loosely tied to subscriptions:

The stance has always been that an environment refers to a selection of Azure resources deployed. Thus, having environment strongly coupled to the subscription after deployment is the right behavior.

I don't think there should be concepts introduced like "azd-env" and "os-env". I don't think the general user will understand what this means, and benefits from the extra functionality. An environment refers to a collection of Azure resources. The .env file stores environment variables. Creating domain abstractions like these do not provide enough value for its justification.

In the future, we should offer more advanced gestures by migrating environments by changing names, subscriptions, and locations. In the current day, we should not deny functionality like azd env set AZURE_SUSCRIPTION_ID. It is an operation operating on the .env file and can be useful in advanced scenarios that aren't supported currently.

As meta-commentary: It feels like we're applying a microscopic view of the feature description, rather than looking at the broader implications of the feature. I did have some ideas pre-GA to have the team concretely define feature sets and concepts, but did not find the time to fit that in. Perhaps we need to resume those discussions?

[john0isaac]

Is this bug still there?
I tried to replicate it but it's not the same for me (output below)

Repro:

1. cd temp
2. azd init -> Pick minimal
3. set AZURE_SUBSCRIPTION_ID='<sub>'
4. azd provision
5. azd env get-values

PS E:\Repo\azure-dev\cli\azd\build\temp> set AZURE_SUBSCRIPTION_ID="930222c2"
PS E:\Repo\azure-dev\cli\azd\build\temp> azd provision                                    

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

? Select an Azure Subscription to use:  1. Visual Studio Enterprise Subscription (930222c2)

  (✓) Done: Resource group: rg-jdj

SUCCESS: Your application was provisioned in Azure in 44 seconds.
You can view the resources created under the resource group rg-jdj in Azure Portal:
https://portal.azure.com/#@/resource/subscriptions/930222c2/resourceGroups/rg-jdj/overview
PS E:\Repo\azure-dev\cli\azd\build\temp> azd env get-values
AZURE_ENV_NAME="jdj"
AZURE_LOCATION="eastus2"
AZURE_SUBSCRIPTION_ID="930222c2"

Screenshot from .env file