Region Filtering/Sorting

[savannahostrowski]

It'd be neat if we could:
1 - hide regions that are at capacity or inapplicable for a particular app (e.g. because the services are supported there)
2 - sort the regions by which are lowest cost to the developer

I've had some conversations around this with a team in Azure core.

[ellismg]

We have some limited support for doing this in the product today, but the complete end to end is not baked.

When prompting for values for required infrastructure parameters, we will use the @allowed decorator to offer the user a list of parameters.

You can write this in bicep today:

@allowed(['eastus2', 'eastus'])
@metadata({
  azd: {
    type: 'location'
  }
})
param backupLocation string

And then get this experience (if you don't assign a value to backupLocation from main.parameters.json)

(Note, these are the only two options in the list. The type: location metadata tells azd that this list of options is tied to locations, and so that's why you get the nice list with short and long names for locations.)

This is all based on static information, but would let us do things like "well we know this resource has not yet launched in this location, so don't include it in the set of allowed values".

A while back I did write this little program: https://gist.github.com/ellismg/ed960fbc02080e7dfe4f31a013604a4c that tried to use the ARM APIs to understand for a given template, what regions supported all the resources in this template. We could consider doing something like this in the tool as well.

I think I wrote the program before we went all in on bicep modules for re-use, so it might need some updates to handle a template with a bunch of nested deployments.

[tonybaloney]

This is a continuing issue in this azd template because users are picking a region that the template doesn't work in (it only works in 4)!

Azure-Samples/azure-search-openai-demo#288

[pamelafox]

Matt Ellis (@ellismg) Should we be able to use @allowed in azure-search-openai-demo today, to restrict location? (As showed above)

[ellismg]

Matt Ellis (@ellismg) Should we be able to use Myouki (@allowed) in azure-search-openai-demo today, to restrict location? (As showed above)

You can certainly add it to today, but the experience will be less than ideal (maybe better than what the customer would get out of the box today, however!)

The issue is that the initial location prompting does not take this filtering into account. That's something we could fix (#1983 is somewhat related, we prompt for the value even if it is hardcoded and we don't need it), so the user would still be allowed to pick any region. When they ran azd provision, however, they'd get an error like this.:

ERROR: deployment failed: failing invoking action 'provision', error deploying infrastructure: starting deployment to subscription: PUT https://management.azure.com/subscriptions/faa080af-c1d8-40ad-9cce-e1a450ca5b57/providers/Microsoft.Resources/deployments/matell-2387-dev-1687456683
--------------------------------------------------------------------------------
RESPONSE 400: 400 Bad Request
ERROR CODE: InvalidTemplate
--------------------------------------------------------------------------------
{
  "error": {
    "code": "InvalidTemplate",
    "message": "Deployment template validation failed: 'The provided value for the template parameter 'location' is not valid. The value 'eastus' is not part of the allowed value(s): 'eastus2'.'.",
    "additionalInfo": [
      {
        "type": "TemplateViolation",
        "info": {
          "lineNumber": 1,
          "linePosition": 734,
          "path": "properties.template.parameters.location.allowedValues"
        }
      }
    ]
  }
}
--------------------------------------------------------------------------------

(Here I picked "East US" and not "East US 2" from the location selection.)

The fix would be to then run azd env set AZURE_LOCATION eastus2 and then azd provision again. It is nice that this happens before the deployment starts and any resources are provisioned, so that likely helps the user a bit, but it still not a great to end to end. We can do better with some work.

[ellismg]

I spent a little bit of time seeing how hard it would be to take this information into account during our initial location prompting.

https://github.com/ellismg/azure-dev/pull/new/ellismg/influence-initial-region-selection

Is the result of that, and it more or less works. There are still some open questions, specifically, it doesn't work if you do azd up (we continue to give you the unfiltered location list), but I think there's a reasonable path forward.

Pamela Fox (@pamelafox) - Do you have a sense if having this support (just the ability for a template author to control what regions a template was supported in, and a nice UX on top of it) would be helpful in moving the needle on some of the deployment failures folks have been seeing? If this is worthwhile, we can try to prioritize the work.

[crazy4pi314]

FWIW I would love the template level filter since I have run into problems getting weird errors deploying to the wrong region so many time 👍

[pamelafox]

Matt Ellis (@ellismg) Hm, if your approach doesn't work during azd up, in what workflow does it work?

[pamelafox]

Matt Ellis (@ellismg) We're using your earlier suggestion for the OpenAI sample now, it works pretty well since we also had a request to easily specify a different location for the OpenAI resources than the rest of the resources:
Azure-Samples/azure-search-openai-demo#390