Deprecation of Switch-Azuremode

[trondhindenes]

The two "modes" in Azure are painful and confusing to work with. For example, there's two different "Get-AzureVM" cmdlets (one in each "mode"), each listing its own sets of vms (the "ServiceManagement" cmdlet lists "v1" vms and the "ResourceManager" cmdlet lists "v2" vms). This is a horrible design. Please build a PowerShell module where every module is available without having to perform confusing operations like "Switch-AzureMode": The Azure module is the only module on the planet with two modes, and for good reasons: It is a plain stupid design.

[brantb]

Starting in v0.9.2, running Switch-AzureMode now emits a warning with the message "The Switch-AzureMode cmdlet is deprecated and will be removed in a future release.", so it looks like you're getting your wish, but there doesn't seem to be any indication as to what (if anything) is replacing it.

[singhkays]

Adding @devigned. There should be more information on this in the next few days

[devigned]

Nothing has changed other than a warning, which will be followed up with some azure.com guidance (landing this week) regarding the upcoming changes and timeline for these changes.

We don’t expect to fully deprecate switch azure mode until after summer. Since it is such a large change, we want to start to warn users and get them thinking about what it means to no longer use switch azure mode. This change will be most impactful for users who are using both ASM and ARM cmdlets.

I'll reply back to this issue with the aforementioned guidance. Based on that guidance and timeline, we'd love to get some feedback regarding the upcoming changes and incorporate that feedback into the proposed solution.

[trondhindenes]

Thanks for the feedback, @devigned ! Looking forward to more info on this.

[juneb]

Ogail, David, is there any guidance for partners? Our products have custom code to handle the ASM/ARM switch and I can't wait to remove it.

[markcowl]

@juneb There will be an article soon. The practical upshot is that switching mode will no longer be necessary as you should be able to load both modules at the same time.

[trondhindenes]

Great news. Could you explain what will happen to v1/v2 vms as a result of this switch? Will "v2" vms be created by default after the switch? (that would mean that "Get-azurevm" will only list vms created via the arm api while we will have to use "get-asmvm" to list "v1" vms?). I think there's no getting around the fact that we need a unified set of cmdlets that lets us manipulate both v1 and v2 resources, or that v1 resources get converted into v2 resources somehow.

[devigned]

@trondhindenes We will not be converting v1 to v2 resources. Transitioning from v1 to v2 resources is handled by a little differently by each Azure service. You will be able to leverage v1 cmdlets and v2 cmdlets side-by-side to manipulate v1 and v2.

[trondhindenes]

Just to get clarification: "We will not be converting v1 to v2 resources": "We" as in Microsoft, or "we" as in the team working on the PowerShell cmdlets for Azure? What I'm trying to understand here is how I should tell my customers to handle this. Say you release updated cmdlets on sept 1st that switch to arm as the default api:
august 29: vm is created with new-azurevm, which will create a V1 vm. Get-azurevm lists all vms in subscription.
september 1st: customer updates the azure module from msi or via the Powershell package manager.
september 2nd: vm is created with new-azurevm, which will create a V2 vm. Get-azurevm lists only v2 vms in subscription.

Am I correct in assuming this?

[devigned]

We as in Azure PowerShell.

The script that is calling New-AzureVM will fail as V2 expects different parameters than V1.

[devigned]

@trondhindenes let me be a little more specific. The customer could also leverage a backwards compatibility script that we'll provide. This will make the script run as it would have before, but it is only meant to be a stop gap for folks only using ASM cmdlets.

[jodoglevy]

The full proposal from Azure PS and Azure Automation teams is here: https://github.com/Azure/azure-powershell/wiki/Deprecation-of-Switch-AzureMode-in-Azure-PowerShell

[alexandair]

New Azure modules won't be offered through WebPI?
When you put new modules to PowerShellGallery, so that we can use PowerShellGet to install them, the installation path will change to c:\Program Files\WindowsPowerShell\Modules (by default) or equivalent path for the 32-bit modules. Is that correct?