Allow setting session configuration path (especially/account/subscription/token) - AZURE_CONFIG_DIR equivalent

[ohadschn]

Description of the new feature

az cli supports setting its session configuration folder (including current account/context/subscription/token) via a AZURE_CONFIG_DIR environment variable: https://docs.microsoft.com/en-us/cli/azure/azure-cli-configuration#cli-configuration-file.

This is extremely useful for the case where one works concurrently against multiple accounts (even in different cloud instances, e.g. Public/Mooncake/Fairfax/BlackForest): https://github.com/Azure/azure-cli/issues/1347

It might also provide a path for improving the PowerShell concurrency/Start-Job experience: https://github.com/Azure/azure-powershell/issues/9448

Proposed implementation details

Allow overriding the currently used %LOCALAPPDATA% with a user-supplied environment variable (e.g. AZ_CONFIG_DIR).

[dingmeng-xue]

PowerShell cmdlet syntax is different from CLI syntax. The syntax supports mandatory parameter or optional parameter. If mandatory parameter is changed to optional and relies on default setting, user cannot understand cmdlet original design and its corresponding rest API.

Recently, we also found a problem on default resource group. Currently, some services allow to fetch resource across resource groups in one subscription. In that case, resource group becomes optional. Consequently, implementation of cmdlet cannot tell how to handle the logic when user doesn't provide resource group.

Azure PowerShell is aiming to automation environment and user is sensitive to breaking change. We'd like to make cmdlet syntax more accurate and be conservative on syntax change.

[ohadschn]

The az cli syntax also has mandatory or optional parameters, much like the Az PowerShell CmdLts. For example, all the parameters of az resource list are optional, and whatever isn't specified is either taken from the current context (like the subscription), or expands the scope of the command as you specified (e.g. fetch across resource groups).

But all that is beside the point - I am not suggesting any breaking change at all. I'm saying keep everything exactly as it is, but allow me to set an environment variable that will effectively create an additional "sandboxed" Az Powershell instance with its own context. Basically just save all the current context information you're already saving today to a different folder, instead of the currently hard-coded one inside LOCALAPPDATA. In other words:

1. If the proposed AZ_CONFIG_DIR env var is not changed, nothing changes at all, and Az PowerShell behaves exactly the same as it does today.
2. If the proposed AZ_CONFIG_DIR env var is changed to some other folder, Az PowerShell behaves as if I'm working on a different computer (it has its own default settings, own context, own tokens etc.) but otherwise exactly as it does today.

I can actually achieve this effect today by using multiple WSL instances, but it's just not as convenient - I have to update PowerShell in all of them, make sure all my other tools are there and generally manage multiple containers instead of one...

[dcaro]

@ohadschn Azure PowerShell has several cmdlets to manage contexts and offers the possibility to not save it on disk with Disable-AzContextAutosave and use Import-AzContext to load a context from a file.

We will be considering your suggestion for handling defaults parameters in Azure PowerShell more globally. Such a change need to be carefully implemented and tested. For example Get-AzVm list existing VMs in a subscription, if a resource group is specified in a config file, the request would be bound to that resource group as expected, but how do you get the list of all VMs in the subscription? This is the type of regression that we need to evaluate.

[ohadschn]

@dcaro let me reiterate that I'm not suggesting any change at all to the way Az PowerShell behaves, be it in terms of global/default parameters, default context persistence, or otherwise. Nothing in my proposed change will cause any regression in any use case. If Get-AzVm grabs all VMs in the sub, let it continue do so.

I'm just saying that whatever context you do persist, let me configure the folder where it's persisted (rather than the currently hard-coded one under %LOCALAPPDATA%) - regardless of how it's going to be used by the CmdLts after (which again, will use it exactly as they are using it today). That persisted context already includes the current token and the currently active subscription (the two most important things), and I'm not asking to change it - just save it in a different folder.

So for a user that doesn't set this proposed AZ_CONFIG_DIR, nothing changes whatsoever. And for a user that does change that folder, again nothing changes, except that the user will get an experience equivalent to opening a PowerShell terminal on a different machine (or in my equivalent case WSL), because all their actions (login, set active sub, logout, etc) will be performed against a separate folder.

This will allow the user to work against multiple accounts/clouds at the same time on the same machine, using multiple PowerShell sessions, each one configured against a different folder - exactly as they do in az cli: https://github.com/Azure/azure-cli/issues/1347.

[dcaro]

Sorry for the misunderstanding, this in our backlog.

[dingmeng-xue]

Hi @ohadschn ,

We hope to evaluate the benefit of making it configurable. The folder has been introduced for couple years and changing it requires lots of efforts. For the time being, it sounds this configuration allows user to work with multiple accounts/clouds at the same time. Is it the common case? I believe user may use incorrect AZ_CONFIG_DIR easily.

[ghost]

Hi, we're sending this friendly reminder because we haven't heard back from you in a while. We need more information about this issue to help address it. Please be sure to give us your input within the next 7 days. If we don't hear back from you within 14 days of this comment the issue will be automatically closed. Thank you!

[ohadschn]

hi @dingmeng-xue,

1. I can't speak statistically, but I'm guessing many customers would own multiple subscriptions. Working against multiple subscriptions, each in its own CLI window (where you perhaps change the title to refect the current sub) can be really convenient.
2. I'm not sure how AZ_CONFIG_DIR could be used incorrectly - the majority probably won't use it at all, and those who do will probably know what they are doing (it's a pretty simple concept after all). The probable worst case is that they'd have to log in again or something to that effect.
3. Forgive my ignorance, but couldn't it be as simple as using AZ_CONFIG_DIR instead of LocalApplicationData - at least for a simple implementation that say doesn't allow changing the user root dir after startup (e.g. after the first command has been called)?