Add support for profiles

[jhendrixMSFT]

Investigate adding profile support to track 2. Ideally this would be based on resource type, not resource provider like we did in track 1.

cc: @kimprice @mikekistler

[jhendrixMSFT]

Sketching out an implementation (not comprehensive but conveys the general pattern).

/sdk/profiles
+------------/20200901hybrid
             +--------------/doc.go
             +--------------/go.mod
             +--------------/keyvault
                            +--------/azkeys
                            +--------/azsecrets
             +--------------/resourcemanager
                            +---------------/compute
                                            +-------/armcompute
                            +---------------/resources
                                            +---------/armlocks
                                            +---------/armpolicy

[jhendrixMSFT]

One problem I see is for the data-plane packages (key vault and blob storage). Our track 2 data-plane packages typically have a hand-written convenience layer on top of the generated code. Scaling this to all profiles isn't sustainable. For key vault, we could probably get away with a 100% codegen solution, although it would mean that the profile versions of key vault would have a slightly different API than their non-profile counterparts which will impact migrating away from a profile or sharing some common code with profile/non-profile services (I don't know how common this is). Blob storage is the most problematic as a 100% codegen solution for it just isn't feasible.

[bganapa]

Current AzureStack SDKs have resource types that are not supported in the AzureStack cloud. Main reason being autorest generates based on the input files given. Core resource providers like compute has not split the swagger files in to per resource type files. However wherever possible, we include only the resource types supported while generating the SDK. e.g Network has per resource type files and we have profile specific tags including only the needed files

Also we need new track 2 SDK only for the profile 2020-09-01-hybrid profile. We do not need to ship track2 SDKs for the 2019,2018,2017 profiles

For Storage/Keyvault dataplane SDKs, Java/C# are going towards having single package supporting multiple api versions. This means that there is no need to ship separate packages for azure stack. For Go, we could copy the storage plane sdks from the existing tag?

Alos it sounds like KV and storage have manual written part which would differ from the latest. Ideally profile specific dataplane sdks should follow the same programming paradigm as Azure. The most common scenario is porting apps written for Azure in to Azure Stack.

[tadelesh]

Current AzureStack SDKs have resource types that are not supported in the AzureStack cloud. Main reason being autorest generates based on the input files given. Core resource providers like compute has not split the swagger files in to per resource type files. However wherever possible, we include only the resource types supported while generating the SDK. e.g Network has per resource type files and we have profile specific tags including only the needed files

Also we need new track 2 SDK only for the profile 2020-09-01-hybrid profile. We do not need to ship track2 SDKs for the 2019,2018,2017 profiles

For Storage/Keyvault dataplane SDKs, Java/C# are going towards having single package supporting multiple api versions. This means that there is no need to ship separate packages for azure stack. For Go, we could copy the storage plane sdks from the existing tag?

Alos it sounds like KV and storage have manual written part which would differ from the latest. Ideally profile specific dataplane sdks should follow the same programming paradigm as Azure. The most common scenario is porting apps written for Azure in to Azure Stack.

@bganapa For the resource type issue, if we want to do some resource type filter by adding some logic into generators, do we have some common way to know which operation we need to add. For the current profile config, I found it's hard to pair the config with operation/operation group. For example, which operation belong to storageAccounts/blobServices in the spec according to this config.

[bganapa]

@tadelesh Thanks for asking. We do not filter out any operations/operation groups for the supported api version. This means that all the operations are included even though it may not be supported in Azure Stack. Hope that clarifies your query.