Deprecation of Switch-Azuremode #428
Comments
|
Starting in v0.9.2, running |
|
Adding @devigned. There should be more information on this in the next few days |
|
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. |
|
Thanks for the feedback, @devigned ! Looking forward to more info on this. |
|
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. |
|
@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. |
|
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. |
|
@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. |
|
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: Am I correct in assuming this? |
|
We as in Azure PowerShell. The script that is calling New-AzureVM will fail as V2 expects different parameters than V1. |
|
@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. |
|
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 |
|
New Azure modules won't be offered through WebPI? |
|
@devigned , in reply to your comment "The script that is calling New-AzureVM will fail as V2 expects different parameters than V1." - |
|
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? |
|
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). |
|
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: Robin |
|
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. |
|
@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. |
|
@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? |
|
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) Are we on the same page? |
|
@alexandair, yes. That's precisely what I was thinking. |
|
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... |
|
@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 |
|
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.) |
|
@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 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. |
|
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] ? |
|
@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. |
|
Sorry for getting to this discussion a little bit to late but I think that this decision will have a HUGE cost on the evolution of the Azure platform as a whole. The adoption of v2 that is already slow is going to be even slower. If you are geting the command in few months for the first time and you see "Get-AzureVM" and "Get-AzureVMRM" which one would you use ? The answer is simple, so we are going to keep hearing that the automation on AWS is a lot easier than is on Azure. And people will not use the deployment template or worst than that will get frustrated because the resources that they create with the template cannot be used by the vm that they created using the PowerShell. This is going to create a lot of frustration in the future. I agree that this decision is the one that is going to give the smaller headache now but the cost of that for Azure in the future will be huge. I hope that this decision can be reverted in the future and we can favor the people that are trying to go forward, and not the ones that stick with the old resources. In my humble opinion if changing the command for {verb}-AzureSM{noun} it is going to break your old scripts and the cost of coordinating that is to high just don't update we should think about the future when taking decisions about new versions and how this will be in years from now. |
|
I am going to disagree with Nepomuceno. And I'll correct him that it's the RM cmdlets that are changing , not the SM ones. That approach will mean less production automation has to be recalled and reworked to cater for this change. The root cause of this change is the two-API monster created by MS in the first place. A more sensible approach would have been to change the SM API to accommodate resource groups, tags, etc. It would have been better to have ONLY had ONE API. But that is not what happened. This initial design decision made things bad, but the decision to create the dual module with similarly named cmdlets that are utterly incompatible just made things worse. I hope these design mistakes will serve as a great warning flag to other teams going down this road (creating multiple APIs, etc). IMHO leaving things as they were was worse than any possible alternative. Two utterly different cmdlets with the same name contained somehow in a single module is simply bad PowerShell. It was confusing to customers and should never have happened. Fixing that mistake is going to cause pain, no matter HOW it was done - NOT doing it would have been worse. IMO. Leaving the older Azure cmdlets alone and only changing the ARM cmdlet names is possibly the best of a bad situation. I still think refactoring the RM cmdlets into different modules is unnecessary and possibly confusing. All the more so when the SM cmdlets are not being refactored. But that's relatively minor given we have module autoload. The decision as communicated to keep the SM cmdlets and redo the RM cmdlets appears to be the least bad of the alternatives. I appreciate that tough decisions had to be made and am glad they've been made and we are moving forward. |
|
Once again, PowerShell already handles command name conflicts. Calling a command, with a conflicting name is done as follows:
The Microsoft team has already picked a direction though, and are going with it. I don't like it, but it's at least a step above where we are at today. All they really had to do was break out the separate modules and install them both at the same time into We are in this mess because Microsoft chose to skirt around the built-in PowerShell mechanisms, and the "new" solution is doing the same thing, just to a lesser degree. Instead of relying on module prefixing, a PowerShell standard, they are renaming commands to avoid having to rely on that built-in mechanism. It really makes zero sense, and will only confuse users more, with ugly command names. Cheers, |
|
Trevor - I agree to your 1st and 2nd points. As for point 3 - I'm not convinced forcing module name prefixes is a great solution - it makes long command lines even longer! |
|
I agree with Trevor, only install the modules you need and if using both modules use the module prefix should have been the solution, it works even in Azure Automation. I just wish we could get the new module and move past this issue and ensure all of the cmdlets have the proper documentation. |
|
Don't forget that there are scenarios when you need to use both ASM- and ARM-based cmdlets, just because some of the functionalities are still not implemented as ARM cmdlets. |
|
The question is actually quite simple is about how the things will look in On 21 August 2015 at 15:41, Thomas Lee notifications@github.com wrote:
|
|
@Nepomuceno +1, if they're going to destroy the command names, they should destroy the ones that are going to be deprecated, rather than ruining the "new" user experience. Cheers, |
|
Well, after the old ones are gone what stops us from aliasing the ARM cmdlets back to the "Azure" names :)? |
|
If we want to go back after we are going to be in danger of breaking
|
|
@Nepomuceno there are many options. That certainly is one that would work. |
|
@devigned Nothing stopping you from aliasing them in the future, but you might want to consider the confusion to end users before making such decisions. |
|
@pcgeek86 any major choices will have the community involved. |
|
@Nepomuceno in terms of how they'd choose between New-AzureVM and New-AzureRMVM, its the same as how they choose between New-AzureVM (ASM) and New-AzureVM (ARM) today. Except now the names will be different, so it will be less confusing in documentation and samples. On top of that, if they are just starting out with Azure, they should use New-AzureRMVM since it is the new V2 VM model in Azure. If they don't know to do that then it is a failure in our documentation, and not related to cmdlet names, since regardless of cmdlet name they are picking the old model. I think what might help is if the Azure PowerShell installer let you choose whether to install the ASM cmdlets, the ARM cmdlets, or both, and for ASM labeled them as "V1, deprecated" and for ARM as "V2, recommended". Same on PSGallery. @devigned may be something to consider. @pcgeek86 don't you think calling the adding of "RM" to cmdlet names as "destroying" and "ruining" them is a little much? You are a PowerShell MVP, so you know about prefixing. Most people do not know or use prefixing in their PowerShell scripts, because cmdlet names are almost always unique, which they should be. Prefixing is just a get out of jail free card. Can you suggest a better prefix? Maybe "AzureV2" instead of "AzureRM"? |
|
I don't really think it's a "little much." I think it's an accurate assessment of how they are today, versus what they are becoming. If you tried doing the same thing in a PowerShell module that was much more popular with other PowerShell MVPs, you would have a similar uproar. The Azure PowerShell module is naturally "benefitting" from the lack of input from most PowerShell MVPs, who aren't using Azure. I don't have to be a PowerShell MVP to know about module prefixing. It has been around for 10 years, and is simply a matter of training / awareness. Trying to solve a training problem with a technical solution is an exercise in disaster. I can't suggest a better noun prefix; I can only suggest using module prefixing, as defined by the PowerShell language specification. Cheers, |
|
To the Azure PowerShell team, where do you stand in regard to the estimated dates you had listed above, ie 'Release PowerShell 0.9.9 ~ 8/25'. Just trying to prep some customers for the change. |
|
@larrywa we are targeting 10/01 for release at this point. We will still include 0.9.8 in the WebPI feed, so teams are not required to install the breaking changes. There will be a second feed item for this release. |
|
Update is Oct. 8th release. |
|
I'm really surprised why does Microsoft reports each time the new change. You should know that there are customers using Powershell and Resource Manager on production, and we spend a lot of time to prepare the switch. And then, 1 hour/day before the change release, we are informed of the report time. Please, we support Microsoft because they follow Enterprise processes which respect the customers needs. |
|
@SamirFarhat To the defense of the Microsoft Azure PowerShell team, they have taken a leading approach to inviting and accepting customer feedback. In this particular case, they have not rushed into anything, and have been very solid about communicating with their customers, partners, and MVPs. I think that, in this case, the feedback is somewhat misdirected. There are plenty of other Azure feature teams rushing out features and functional changes, that your feedback would probably be better served to. Honestly, the Azure PowerShell team is doing some of the best work out of the entire Azure platform, in terms of customer engagement. I still think that the Azure identity team (Travis Gross' team) is the absolute leader, and Azure Automation (Joe Levy's team) closely follows, but David and team are doing great work. Cheers, |
|
Hi Trevor, |
|
Valid point Samir. MS (although the do their best I'm sure) has a pretty bad track record when it comes to delivering on promised dates. We've given them a ton of feedback on this and communications in general needs improving, so we can only assume they listen. |
|
Hi people, I wanted to know few things- Hoping this is the right platform to ask these questions! |
|
Oct 8th is now passed, any release coming soon? |
|
Sakshi: While with GitHub one can update a version, the tradition in this project is that each changed version is a new module. So anything that works in that version will continue to work forever. OF course, when I say forever - I mean the client side behaviour should not change. Remember that the cmdlets are a wrapper around the 'real' API, which is REST based. This API can and sometimes does change - and those changes may render features in 0.9.8 no longer usable or compatible with the updated API. While I would not expect that to happen - Azure is evolving at 'Internet speed' and with that haste comes issues - so never say never. WIth that said, you should be safe with 0.9.8 for some time. I would expect that should I be wrong in that assertion, we'd have plenty of warning and explanation here well in advance. |
|
The new version is released: https://github.com/Azure/azure-powershell/releases/tag/v1.0.0-preview-gallery-October2015 |
|
Closing (!!!!) |
HPF PR: vmss <- huangpf:dev
and others
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.
The text was updated successfully, but these errors were encountered: