Support resource picker for parameters

[heaths]

azd supports a few "pickers" for parameters without default values today e.g.,

@metadata({
    azd: {
        type: 'location'
    }
})
param frontendLocation string

Just like for any parameter named location, you'll prompt with a list of locations. This is also supported for a couple other types like generate.

It would be great to add support to query resources of a specific type e.g.,

@metadata({
    azd: {
        type: 'resource'
        resourceType: 'Microsoft.OperationalInsights/workspaces'
    }
})
param frontendLocation string

This would list all the resources of that type discoverable to the user. Ideally, the display would put the location in parenthesis since they may want to limit those resources to just a location but you would have a hard time doing it above in any meaningful way because you'd either have to author it up front (not flexible), tie it to the location parameter (which you'd have to parse as an expression), or maybe just define a useLocation: bool parameter and use the location after you've already prompted/assigned it. Not sure how useful any of that would be, but listing names like "{name} ({location})" would be easy and useful, since ARM gives you back the locations as well.

E.g. az CLI command:

az resource list --resource-type Microsoft.OperationalInsights/workspaces

Scenarios

The reason why this would be useful is to provide a friendly interface for selecting resources you may want to reuse like AppInsights workspaces (often aggregates apps; this is my impetus for filing this feature request), dashboards (again, often aggregates), or for more expensive resources with multi-project support like Cognitive Services that may also pull from different organizational resources anyway.

It's possible now by passing an environment variable and using that in your .parameters.json file, but it's more work up front and doesn't really fit the UX you already have: you prompt for subscription and location already. Those could also be passed as required parameters but you provide a friendly UX to list them. Getting the resource ID of an existing resources can be a rather daunting task, so it seems that could be made easier as well for those "Getting started" scenarios that some azd users are trying to provide for their downstream users e.g., if we used azd in our Azure SDKs' "Getting started" sections instead of az CLI commands.

[heaths]

And does azd always prompt for subscription then location before processing other parameters? I went through the code to see how resource type prompting could work - doesn't seem like too much work - but it would be great to, perhaps, list resources grouped by location and list those resources in the selected/current location first (not change the order, but scroll the list to that location much like you support already for prompters).

[ellismg]

And does azd always prompt for subscription then location before processing other parameters?

I think things are a little ad-hoc today (and we might end up treating the location value a little bit more like every other parameter than something special), but I think we'd be fine to change things up such that we always prompt for these values first.

It would be great to add support to query resources of a specific type e.g.,

@metadata({
    azd: {
        type: 'resource'
        resourceType: 'Microsoft.OperationalInsights/workspaces'
    }
})
param frontendLocation string

I like this and I think it would be generally useful. I know that @wbreza has been playing around with some similar resource picking stuff in some exploratory work he's doing.

Long term we might also want to add some sort of filter thing that allowed you specify some filtering based on properties of the resource - but I think just resource type matching is a great place to start.

[heaths]

Long term we might also want to add some sort of filter thing that allowed you specify some filtering based on properties of the resource - but I think just resource type matching is a great place to start.

That's a good idea. Could unmarshal into a json.RawMessage or something that we could compare to any resource JSON we get back. But, yeah, that could be added later. I'm hoping that, like with the scenarios I described for reasons I provided, there's be few enough of these pre-existing resources to necessitate filtering. 🤞

[heaths]

resourceType is optional. Recommended, certainly, but I could see someone wanting to list all features. Happy to treat this as required, though.

Speaking of which, if the parameter has a description, should we show that in some way? Presumably the template author added a descriptive description to describe what the parameter is for. Seems like a great thing to show in the UX.