Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support resource picker for parameters #4530

Open
heaths opened this issue Nov 8, 2024 · 4 comments · May be fixed by #4535
Open

Support resource picker for parameters #4530

heaths opened this issue Nov 8, 2024 · 4 comments · May be fixed by #4535
Labels
feature

Comments

@heaths
Copy link
Member

heaths commented Nov 8, 2024 •
edited
Loading

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 heaths added the feature label Nov 8, 2024
@heaths
Copy link
Member Author

heaths commented Nov 8, 2024

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
Copy link
Member

ellismg commented Nov 8, 2024

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
Copy link
Member Author

heaths commented Nov 8, 2024

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
Copy link
Member Author

heaths commented Nov 9, 2024 •
edited
Loading

Image

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.

heaths added a commit to heaths/azure-dev that referenced this issue Nov 9, 2024
@heaths
Prompt for resources with optional resourceType
6f18fa8 
Resolves Azure#4530
@heaths heaths linked a pull request Nov 9, 2024 that will close this issue
Open
heaths added a commit to heaths/azure-dev that referenced this issue Nov 9, 2024
@heaths
Prompt for resources with optional resourceType
d14ad7b 
Resolves Azure#4530
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
feature
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Prompt for resources with optional resourceType heaths/azure-dev
2 participants
@heaths @ellismg