Using the Azure schema from powershell

[rdbartram]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

We have built PowerShell modules dynamically from the schema file you have in this repo for the pulumi provider.

pspulumiyaml

It allows us to use the yaml "language" provider and that is great.

One thing we noticed and would like to improve is that there is no relationship between the objects and their respective functions. For example, liststorageaccountkeys and storageaccounts. (This is as far as we know, we would love to be corrected).

A solution that we came up with, was if we have the REST paths for each object, then we could search for functions that use the same REST path and in so doing, create extension methods on the objects and allow users to call directly from the object they instantiated, its respective functions.

I'm not sure this would work for all providers, but for Azure RM at least this seems like a viable solution. The only downside I see is that we add a couple more mb to the already huge schema file.

Affected area/feature

dynamically generated Schema.json

[danielrbradley]

Hi there! pspulumiyaml looks like a super-interesting project!

I agree that this addition would be quite specific to the azure-native provider. I think the information you're looking for might already be available in the metadata.json - which in the file that contains all the azure-specific information for the provider.

Another option could be to just show the underlying path in the documentation and try to make the search pick it up effectively, though from the sound of your use-case you're looking for something more structured to be used from your program, is my understanding correct?

[rdbartram]

thanks @danielrbradley. It seems that the metadata.json only includes the REST paths for functions but not for the resources. This then makes it hard to bind the two together. I have considered scraping the docs but I don't feel like they have this direct link either.

Basically what we have now is a code generation script which reads the schema.json and creates dozens of modules and functions to create everything as one would expect.

A code example we would like to implement would be replacing line 55 in this example with the following or something similar:

$keys = $storageAccount.ListStorageAccountKeys()

[danielrbradley]

The resources section starts around line 1,390,500 and includes a path for each resource:

  "resources": {
    "azure-native:aad/v20170101:DomainService": {
      "apiVersion": "2017-01-01",
      "path": "/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.AAD/domainServices/{domainServiceName}",

The depth to which you're starting to go would indicate that you're heading towards the direction of implementing language support for Powershell. There's an issue tracking Powershell language support, though it's not had much progress made recently.

I'm still a little unclear why you're needing to tie the resources back to their associated Azure API paths. Do you have an existing implementation that currently utilizes the API paths which you're trying to convert to use Pulumi or is it a different reason?

I'm going to convert this issue to a discussion thread as this isn't something we'd currently support directly from this provider as it doesn't align to the wider Pulumi archtecture. You can read more about the inner workings of Pulumi in our developer docs.

[rdbartram]

Ok weird. I did a search and didn’t find it. I’ll take another look.

The reason we need the resource paths is we have not found any other clear documentation that shows which functions “belong” to each resource. And since there are 1000s of functions, it’s not something we want to map manually.

The best idea we’ve come up with so far is to look at the rest paths and most functions we saw are subpaths of resources.

For example

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{accountName}/listKeys?api-version=2021-09-01

we can link this function. To the create rest endpoint

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Storage/storageAccounts/{accountName}?api-version=2021-09-01

We would then do some Tom foolery in the background to match the properties to the parameters of the functions.

If you have a better idea to do this. Because from what I’ve seen the other languages don’t support this either. They all just make static method calls and pass all the parameters from created objects.

[danielrbradley]

Functions can attached to resources via the methods block within the schema. Most functions are just model-level though to sit alongside the resources.

Here's the docs on the schema file: https://www.pulumi.com/docs/guides/pulumi-packages/schema/

[rdbartram]

So I took a look at the definition and the method property of the resource in the schema is exactly what we are looking for! The unfortunate thing is that is is not implemented at all in the Azure-Native provider. In fact I only see it implemented on the EKS one. The question is now, how do we implement this for az-native?

I don't know if there is some legit reference somewhere in the Az APIs to let us know this...but if not, child paths on the PUT API endpoints, can't be a bad shout...