Deployment failed using existing OpenAI resource

gscx233 commented 1 year ago

Please provide us with the following information:

This issue is for a: (mark with an `x`)

- [x] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

Minimal steps to reproduce

Follow the document and use existing OpenAI resource instead of creating new: Run azd env set AZURE_OPENAI_SERVICE {Name of existing OpenAI service} Run azd env set AZURE_OPENAI_RESOURCE_GROUP {Name of existing resource group that OpenAI service is provisioned to} Run azd env set AZURE_OPENAI_CHATGPT_DEPLOYMENT {Name of existing ChatGPT deployment}. Only needed if your ChatGPT deployment is not the default 'chat'. Run azd env set AZURE_OPENAI_GPT_DEPLOYMENT {Name of existing GPT deployment}. Only needed if your ChatGPT deployment is not the default 'davinci'. Run azd up

Any log messages given by the failure

In deployment detail, it shows the OpenAI resource is conflict with existing one.

Expected/desired behavior

When I use existing OpenAI resource, it should not deploy OpenAI resource: { "status": "Failed", "error": { "code": "InvalidResourceLocation", "message": "The resource 'xxx' already exists in location 'southcentralus' in resource group 'xxx'. A resource with the same name cannot be created in location 'eastus'. Please select a new resource name." } }

OS and Version?

Windows 7, 8 or 10. Linux (which distribution). macOS (Yosemite? El Capitan? Sierra?)

Versions

Mention any other details that might be useful

Thanks! We'll be in touch soon.

jongio commented 1 year ago

Please try adding the following param to /infra/main.parameters.json

    "openAiResourceGroupLocation": {
      "value": "southcentralus"
    }

Then run azd up again.

github-actions[bot] commented 6 months ago

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this issue will be closed.

Lawndemon commented 3 months ago

the deployment expects all resources to be in the same region but so many regions do not have OpenAI or, like canadaeast, have only OpenAI. I had to jump through a lot of hoops to get this to deploy with resources in multiple service regions but it is possible. Best hack option is to hardcode the key for your OpenAI resource into the deployment script. The longer-term fix was to add a new param called openailocation (or something similar) and then rewrite the OpenAI deployment sections to use this for the openai location. It's not a plug&play/find&replace fix though - there are some pretty baked in dependencies in this project that require it to be in one region.

pamelafox commented 3 months ago

@Lawndemon We have an existing parameter for the location, for that reason: openAiResourceGroupLocation

What was the difference between openAiResourceGroupLocation and the new parameter you added?

Lawndemon commented 3 months ago

I don't want to create a new resource group, I want the resource to be in a different location but in the same resource group. All of the services other than OpenAI are in 'canadacentral' while the openai location is 'canadaeast' but all in the same resource group for simplicity. I recommend an option to set the location for the openai service without having to setup a different resource group for it. Unless the variable 'openAiResourceGroupLocation'is just for the OpenAI location and the term "ResourceGroup" in the variable name is not indicative of what the variable is doing? In which case I've wasted a lot of time - lol!

@pamelafox can you confirm that the variable "openAiResourceGroupLocation" represents only the location of the OpenAI service and is not part of defining a different resource group for OpenAI? Meaning, the param could also be called openAIResourceLocation?

pamelafox commented 3 months ago

It is confusingly named. The Bicep only creates a new resource group for the OpenAI resource if you also explicitly set openAiResourceGroupName (or AZURE_OPENAI_RESOURCE_GROUP azd environment variable). Otherwise, it creates the OpenAI resource inside the existing resource group, but at that location.

egor-yudkin commented 2 months ago

@pamelafox I observed similar behavior as reported by @gscx233 when Azure OpenAI resource and the rest of the application use the same resource group, but different location (e.g. most of resources are in eastus and OpenAI is in eastus2) - we do this due to OpenAI models availability limitations. The problem itself occurs only on re-deployment though. Initial deployment works fine.

I noticed that in such case main.bicep updates respective OpenAI environment variable incorrectly:

resource openAiResourceGroup 'Microsoft.Resources/resourceGroups@2021-04-01' existing = if (!empty(openAiResourceGroupName)) {
  name: !empty(openAiResourceGroupName) ? openAiResourceGroupName : resourceGroup.name
}

~~~~rest of the bicep file~~~~

output AZURE_OPENAI_RESOURCE_GROUP_LOCATION string = isAzureOpenAiHost ? openAiResourceGroup.location : ''

As I'm using the same resource group for OpenAI resources, AZURE_OPENAI_RESOURCE_GROUP_LOCATION env variable effectively gets populated with that resource group location. And it doesn't match with the actual OpenAI resource location. So next time I hit azd up it tries to create a new OpenAI resource with the same name but in the "primary" resource group region, which fails.

The solution that works for me is to use already existing openAiResourceGroupLocation parameter like this:

output AZURE_OPENAI_RESOURCE_GROUP_LOCATION string = isAzureOpenAiHost ? openAiResourceGroupLocation : ''

I can submit a pull request for this if you are ok with this solution

Azure-Samples / azure-search-openai-demo