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?

[sriramvu]

@devigned , in reply to your comment "The script that is calling New-AzureVM will fail as V2 expects different parameters than V1." - For our service, we have planned to have same set of parameters with both V1 & V2 cmdlets (thought of not changing user experience). Can this cause any problem?

[RobinDotNet]

Let's talk about Azure Storage cmdlets. Some of these are in the ARM cmdlets, and I'm guessing that some aren't. Is that true? How will we know which cmdlet to use? Are there any in both that are the same in both?

[alexandair]

There will be a lot of cmdlets with the same name in ASM-based module and ARM-based modules. However, they won't have the same parameters. For example, ASM-based Get-AzureVM has one parameter set and -ServiceName parameter. ARM-based Get-AzureVM has four parameter sets and -ResourceGroupName (in two of them).

[RobinDotNet]

Yeah, I got that. I've used both for creating VMs. However, I'm specifically asking about cmdlets having to do with Azure Storage, not VMs, especially the ones that may not be in ARM now. Examples: New-AzureStorageContext -- I wouldn't expect this to change New-AzureStorageContainer -- I would expect the ASR version to require the ResourceGroup Get-AzureStorageContainer -- might have 2 versions, with ASR version requiring ResourceGroup Get-AzureStorageBlob --- I wouldn't expect this one to be different Set-AzureStorageBlobContent -- I wouldn't expect this one to be different Get-AzureStorageBlobContent -- I wouldn't expect this one to be different Start-AzureStorageBlobCopy -- I wouldn't expect this one to be different the same ones for Files

Robin

[alexandair]

Disregard my previous comment. I was thinking about some old discussions with Azure PowerShell team on this subject when we still talked about having the same names for both APIs and using modulequalified naming. With the current proposal, that won't be the case anymore. ASM-based module will have Get-AsmVM cmdlet and ARM-based will continue to use Get-AzureVM.

[devigned]

@sriramvu if the cmdlets exist in both ASM and ARM modules, then there should be no issues. If they will exist in a module that would be used in both, then we should talk through that so we break them up properly.

[devigned]

@RobinDotNet we should talk through breaking those cmdlets out from ASM and ARM if they have nothing to do with them. Sounds like the cmdlets you are mentioning are data plane cmdlets (non-management) and as such should be independent from the management related cmdlets (IMHO).

Thoughts?

[alexandair]

Right now, all cmdlets that @RobinDotNet has mentioned exist in both modes--AzureServiceManagement and AzureResourceManager and are coming from the same DLL regardless of the mode (C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Storage\Microsoft.WindowsAzure.Commands.Storage.dll) I expect them to get their own AzureStorage module and keep their name. They'll continue to work as before. For example, if I want to list all storage-related cmdlets:

Get-Command -Module AzureStorage

Are we on the same page?

[devigned]

@alexandair, yes. That's precisely what I was thinking.

[chadiel]

If we expect both cmdlets to live in the same module, would we be opening our customers to a source of frustration when they get a resource using the ASM cmdlet and try to use it with an ARM cmdlet (or vice versa) only to have the call fail? I'd imagine that a customer who has created a resource that lives side-by-side between ASM (RDFE) and ARM (e.g. SQL, Websites, etc.) to encounter this at some point (after all, from a customer standpoint they are interacting with the same resource and whether its ARM or ASM that is servicing the request is, to the customer, an implementation detail...) I worry that we may be solving one problem and introducing another...

[RobinDotNet]

@alexandair -- ALL of them are in both? But they're not identical. Get-AzureStorageAccount and New-AzureStorageAccount let you pass in a resource group in the ARM side. Does the assembly handle both?

I'm asking because I just wrote about a thousand lines of powershell for a storage course that's going to be hosted by Opsgility (like Pluralsight, but just Azure), and it's due to be published in July, and I'm trying to figure out if I am going to have to change the code or comment about the v1/v2 issue. If the cmdlets don't change, and you guys handle where they're pulled from, that works for me.

Does that make sense?

Robin

[RobinDotNet]

One other thing. You have to deal with the v1/v2 invisibility issue. I mean where you can not see v2 storage accounts from ASM and you can't see v1 storage account from ARM. So if you load both of those, are they going to have to use Get-ASMStorageAccount and Get-AzureStorageAccount in order to see all of their storage accounts? (Considering how many millions of people are using v1 assets on Azure, this would be a p.i.t.a.)

[alexandair]

@RobinDotNet I said all cmdlets that you've listed in your comment are coming from the same DLL in both modes and will work in the future as they are working now. On the other hand, Get-AzureStorageAccount and New-AzureStorageAccount are not in the same DLL. ASM-based ones are in C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ServiceManagement\Azure\Compute\Microsoft.WindowsAzure.Commands.ServiceManagement.dll and ARM-based ones are in C:\Program Files (x86)\Microsoft SDKs\Azure\PowerShell\ResourceManager\AzureResourceManager\StorageManagement\Microsoft.Azure.Commands.Management.Storage.dll That means that new ASM-based ones will be renamed to Get-AsmStorageAccount and New-AsmStorageAccount. ARM-based ones will continue as Get-AzureStorageAccount and New-AzureStorageAccount.

I assume, if you want to work with v1 storage accounts, you need to use Get/New-AsmStorageAccount. Get/New-AzureStorageAccount will see v2 storage accounts.

[RobinDotNet]

You mean the old ones will be renamed to Get-Asm[etc], not the new ones, right? So that goes back to my original question. HOW MANY of them will be renamed? Will the ones that have the same functionality, like Get-AzureBlob, still be Get-AzureBlob, or am I going to have to change ALL of my Get-Azure[etc] cmdlets to Get-Asm[etc] ?

[pzerger]

@RobinDotNet - presumably the new naming convention would be applied to all the ASM cmdlets for sake of consistency. It would be confusing to have only those duplicated across modules renamed.

[pzerger]

In my view, the ARM cmdlets should also be a global module pre-loaded in Azure Automation by default (which is not currently the case). The steps to upload the ARM module (http://bit.ly/1SfgmPA) into Azure Automation are an unnecessary distraction that should be removed for working with core Azure IaaS functionality.

[pzerger]

@devigned did you answer @alexandair question about future module distribution via WebPI? I cannot find an answer in the thread above.

[trondhindenes]

It would be great to get some statement from MS regarding how they plan to deal with migration of V1 resources to V2. I realize that's outside the scope of of the team maintaining the Azure Powershell cmdlets, but it's still a very important part of this discussion.

[tylerd]

The article mentions PowerShellGet multiple times, are you talking about PSGet? Or something different? http://psget.net/

[devigned]

@tylerd see: http://blogs.msdn.com/b/mvpawardprogram/archive/2014/10/06/package-management-for-powershell-modules-with-powershellget.aspx

[devigned]

@trondhindenes I'll pass on your desire to have some wider statement regarding migration from v1 -> v2

[devigned]

@alexandair and @pzerger the WebPI installer will be a facade over script running PowerShellGet. You should expect the same experience for both WebPI and PowerShellGet.

[RobinDotNet]

I never use the WebPI installer, because you have no idea what else is going to be installed. The last time I used it to install the PowerShell cmdlets, it updated the Azure Tools on my box, which I didn't want.

[pzerger]

@RobinDotNet last I updated my system, there is now a Standalone option in WebPI for the Azure PowerShell module I've found harmless and quick to install.

[devigned]

@RobinDotNet per your question, "HOW MANY of them will be renamed?". We don't have the total number, but I'll look into it and provide an answer.

To provide a less concise answer, any cmdlet that is inextricably tied to ASM will be renamed. Some of the examples you listed like Get-AzureBlob are "data plane" rather than "management plane" and I would not consider them linked to ASM or ARM. Data plane cmdlets should not have a name change.

[devigned]

@pzerger thank you for pointing that out. We have received quite a bit of feedback similar to @RobinDotNet mentions above. We specifically added the standalone option to assuage this pain.

[RobinDotNet]

@devigned @pzerger Thanks for the info on the WebPI. I've had a lot of trouble with that thing over the years, so I try hard not to use it any more. @devigned That's good news. I was hoping you wouldn't rename the ones that have nothing to do with resource manager/group.

[mvanotti]

Hi! Where can I read more about this v1/v2 resource versioning? I created VMs from the Azure Web Portal last week and I can only see them from the Get-AzureVM cmdlet from the ASM, I can't see them from the ARM one.

It is REALLY confusing to have two different ways to list resources, and I thought that it would be for legacy resources, but the vm's I'm talking about where created last week via the azure portal :/

[RobinDotNet]

I'm concerned that changing all of the v1 Powershell cmdlets is going to be a lot more confusing to the many people using them than teaching people to use Switch-AzureMode. How many people are using these -- thousands? hundreds of thousands? millions? I would bet that 99% of them have v1 assets.

It's so clearer to me to switch to the other set of cmdlets than to figure out which cmdlet I'm going to use. Especially as noted above that not all of them will change (such as the ones from blob storage that I mentioned). So you have to figure out if the ones you use or want to use have been renamed or not.

How did you guys decide to go in this direction? Did you happen to poll the Azure MVP distribution list and/or the Azure Insiders and ask for opinions? (If so, I didn't see it.) A lot of the MVPs do consulting and have a lot of customers, and would be able to give you some kind of prediction on how this is going to go over.

I hate to see you do this and just get a shi*storm over it. And I'm curious what kind of input went into the decision.

[RobinDotNet]

@mvanotti You can't create v2 resources in the preview portal yet. You can only create them with the ARM cmdlets. The v1 resources and the v2 resources can not see each other, so you can't create a v1 storage account and have it used by a v2 resource (and vice versa). And not everything in v1 is in v2. I got toasted last week because it turns out the gateways are not yet available, so you can't set up site-to-site networking to the v2 resources. (And you can't put a v2 VM into a v1 virtual network.) I assume the visibility issue will always be the case, until the v1 assets are migrated to v2. You can see the v2 assets in the preview portal -- they are in separate "directories". For example, if you have v1 and v2 VMs, you will have a folder for VMs and a folder for VMs (v2).

[alexandair]

mvanotti The other way to get v2 resources is to use ARM templates to create compute, networking, and storage resources.

[RobinDotNet]

@alexandair -- You're right. My last customer wanted to use PowerShell, not the templates, so I wasn't thinking about that.

[alexandair]

RobinDotNet The main reason for going in this direction is that Switch-AzureMode is not supported in Azure Automation. ARM is the future, and we need support for ARM-based cmdlets in Azure Automation sooner rather than later. No one says it will be easy. Transitional period is always PITA.

[mvanotti]

If this is already decided, then the first thing to do is add the replacement commands so now people that needs to access the legacy cmdlets can do that. I, for example, see myself using Get-AzureVM (for v1 vms) a lot, and if that function is going to be changed to Get-ASMVM, I would like to have those cmdlets available sooner rather than later.

[mvanotti]

@RobinDotNet, @alexandair thanks for your answer :)

I'm looking for docs that describes the new things about v2 stuff, is there such thing documented?

[RobinDotNet]

@mvanotti Hahaha! That's funny. Hahaha! I mean, no. There's nothing about the visibility or about what features aren't available. My customer had to revert to v1. After discovering the network gateway lack, he was unwilling to continue, afraid we would hit something else that was missing.

Here are some helpful links I found.

I had considerable trouble creating my customer's infrastructure in PS (2 vm's in a load balancer and availability set). This shows how to do that, but doesn't explain why you're suddenly configuring nics and load balancers, which you didn't have to/couldn't do in v1.

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-create-windows-powershell-resource-manager/

Also helpful was Neil Mackenzie’s blog article:

http://blogs.msdn.com/b/cloud_solution_architect/archive/2015/05/05/creating-azure-vms-with-arm-powershell-cmdlets.aspx

and most of all, his gist: https://gist.github.com/nmackenzie/042bdffdfa6098f5063a

This is about the templates: https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-deploy-rmtemplates-powershell/

And this is from Corey Sanders talking about the differences. https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-azurerm-versus-azuresm/

And this is from Ignite. Start at 7 minutes to learn about the different object models. http://channel9.msdn.com/events/Ignite/2015/BRK3505

Good luck to us all. Robin

[RobinDotNet]

@alexandair Ohhhh, I see. It's going to be a huge impactful change that's probably going to make some people angry. I wish Microsoft luck with it, and hope it works out okay.