Add support for Azure Stack

[yatna]

Current Status - Functionality like deploying function to new app, creating new app (advanced), viewing function app files does not work.

Approach - The problem arises mainly because Azure Stack doesn't support the same API version of azure-arm-storage and azure insights. We plan to dynamically load the correct library versions depending on environment. Here the steps -

1. Install all required versions

   "azure-arm-storage": "npm:azure-arm-storage@^4.0.0",
   "azure-arm-storage3": "npm:azure-arm-storage@^3.0.0",

2. Determine the environment by looking at the settings.json
3. Use the correct version of library dynamically using if...else... in all files.

Maintenance - We only load a different library when the environment is Azure Stack, so functionality for Azure won't be affected in any way. If the version AzureStack supports changes, we only need to update the package.json file.

[ejizba]

How do we know which versions of the API are supported by Azure Stack? Are there any major differences between the two api versions affecting our extension? If not - we might as well stick to one api version that works for both

[bganapa]

@EricJizbaMSFT The supported API versions in azurestack is documented at https://docs.microsoft.com/en-us/azure-stack/user/azure-stack-profiles-azure-resource-manager-versions?view=azs-2002 , We define a API Profile for the set of resourcetypes : api versions supported in Azure Stack. The latest existing profile map is available at aka.ms/2019profile

We can certainly stick to one api version that supports both azurestack and azure, but often times azure wants to move on to using the latest api version for new features and azurestack lags behind.

For storage the following are the supported api versions at the moment Storage data plane - 2019-02-02 storage mgmt plane - 2017-10-01

By the end of Fe, azure stack will have support for the following api versions Storage data plane - 2019-02-02 (same as current) Storage mgmt plane - 2019-02-02

We also noticed that some of the operations are using Microsoft.Insights and it is using a very old api version 2015* which is not supported in azure stack.

Having a single SDK supporting multiple api versions is one of the future goals of azure sdks which will help us well here

[ejizba]

We can certainly stick to one api version that supports both azurestack and azure, but often times azure wants to move on to using the latest api version for new features and azurestack lags behind.

Well it only matters if our extension wants to move to the new features, not Azure. If/when that happens, we would need a different plan for how to handle Azure Stack for the new features (since it obviously won't work).

[ejizba]

If "2017-10-01" works for all of our scenarios, that seems like the easiest solution to me. If not (that does sound a bit old), it would be nice to know which scenarios require the newer sdk and thus won't work on Azure Stack.

Having a single SDK supporting multiple api versions is one of the future goals of azure sdks which will help us well here

That would be great. Is there a link to an issue for this? Even if the current sdk doesn't "officially" support multiple api versions, it could be worth adding our own logic to replace the api version on an ad-hoc basis for Azure Stack. That type of logic might fit well in createAzureClient, which all of our extensions leverage.

[bganapa]

@EricJizbaMSFT For short term, starting with supporting 2017-10-01 alone is fine, unless azure requires a newer version for newer scenarios.. For the long term, we will be in need of supporting multiple api versions side by side.

Azure Stack is a boxed product and we support the last three released versions. We release every 2 months. At a given time, even within AzureStack , one customer may be using the Storage RP that supports api version A and another Azurestack customer with a latest ApiVersion B.

The goal should be the customer could install the latest version of vscode extension and target any supported versions of AzureStack or Azure.

We ease the pain of choosing multiple api versions for azure stack with the concept of API Profile . The tools CLI/PS and all the SDKs are referred with APi Profile name for the azurestack supported versions. more details in the below link https://docs.microsoft.com/en-us/azure-stack/user/azure-stack-version-profiles?view=azs-2002 Essentially the customers need not worry about the individual RP versions, rather they refer to a set of api versions with a API profile name

In vscode , we expect to have a user setting like target_api_profile and depending on the value, the vscode extensions should be loading the needed api versioned packages.

[bganapa]

it looks like there is no @azure/arm-storage package that supports the api version 2017-10-01. filed an issue here to follow up https://github.com/Azure/azure-sdk-for-js/issues/10390

[ejizba]

For the long term, we will be in need of supporting multiple api versions side by side.

This is my preferred short term solution. What all do we need to do to enable this?

[AzCode-Bot]

This issue has become stale and is at risk of being closed. The community has 60 days to upvote the issue. If it receives 5 upvotes we will keep it open and take another look. If not, we will close it. To learn more about how we handle issues, please see our documentation.

Happy Coding!

[bganapa]

We are going to evaluate the options in the coming month

[ejizba]

I'll put this in our tracking milestone which will prevent the bot from doing anything, since you guys are working on this, not us.