fix: deploy with separate locations for models and other foundry projects by therealjohn · Pull Request #7873 · Azure/azure-dev

therealjohn · 2026-04-22T15:23:29Z

This pull request updates how Azure location environment variables are handled for AI/model resources and resource groups, improving clarity and flexibility in regional configuration. The main focus is on distinguishing between the deployment location for AI resources and the general resource group location, ensuring both are set appropriately and allowing for independent changes when needed.

Environment variable handling improvements:

The logic for setting the Azure location in loadAzureContext now prefers AZURE_AI_DEPLOYMENTS_LOCATION for AI/model resource deployments, falling back to AZURE_LOCATION for backward compatibility. (cli/azd/extensions/azure.ai.agents/internal/cmd/init_foundry_resources_helpers.go)
The ensureLocation function now sets both AZURE_LOCATION (for resource groups) and AZURE_AI_DEPLOYMENTS_LOCATION (for AI/model resources) to the same value by default, but allows AZURE_AI_DEPLOYMENTS_LOCATION to be changed independently later. (cli/azd/extensions/azure.ai.agents/internal/cmd/init_foundry_resources_helpers.go) [1] [2] [3]

Project selection and environment updates:

When selecting a Foundry project, the deployment location for AI resources is set using AZURE_AI_DEPLOYMENTS_LOCATION, and AZURE_LOCATION is seeded only if not already set, allowing the user to override it before deployment. (cli/azd/extensions/azure.ai.agents/internal/cmd/init_foundry_resources_helpers.go)
In the model selector, updates now target AZURE_AI_DEPLOYMENTS_LOCATION instead of AZURE_LOCATION, and the success message reflects this change. (cli/azd/extensions/azure.ai.agents/internal/cmd/init_models.go) [1] [2]

Matching bicep updates: Azure-Samples/azd-ai-starter-basic#58
Fixes #7670

- Use AZURE_AI_DEPLOYMENTS_LOCATION for model filtering, falling back to AZURE_LOCATION for compatibility. - Ensure both AZURE_LOCATION and AZURE_AI_DEPLOYMENTS_LOCATION are set during initialization. - Update success messages and error handling to reflect changes in variable names.

Copilot

Pull request overview

This PR updates the azure.ai.agents extension’s environment/location handling to distinguish the deployment region for AI/model resources from the resource group region, addressing failures when Foundry projects and RGs are in different Azure regions.

Changes:

Prefer AZURE_AI_DEPLOYMENTS_LOCATION (fallback to AZURE_LOCATION) when loading AzureContext.Scope.Location for model filtering.
Update init flows to set/seed AZURE_AI_DEPLOYMENTS_LOCATION independently from AZURE_LOCATION.
Update the model selector to persist location changes to AZURE_AI_DEPLOYMENTS_LOCATION and reflect this in output messaging.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
cli/azd/extensions/azure.ai.agents/internal/cmd/init_models.go	Writes model deployment location updates to `AZURE_AI_DEPLOYMENTS_LOCATION` and updates the success message accordingly.
cli/azd/extensions/azure.ai.agents/internal/cmd/init_foundry_resources_helpers.go	Loads location with new precedence, sets both env vars during prompting, and updates Foundry project selection to set AI deployment location and conditionally seed RG location.

Comments suppressed due to low confidence (1)

cli/azd/extensions/azure.ai.agents/internal/cmd/init_foundry_resources_helpers.go:756

This warning message hardcodes AZURE_LOCATION, but at this point azureContext.Scope.Location may actually reflect AZURE_AI_DEPLOYMENTS_LOCATION (due to the new precedence in loadAzureContext). Consider adjusting the message to reference the actual variable(s) being validated (or use a generic “current location” wording) to avoid misleading users.

		fmt.Printf("%s", output.WithWarningFormat(
			"The current AZURE_LOCATION '%s' is not supported for this agent setup. Please choose a different location.\n",
			azureContext.Scope.Location,

Copilot · 2026-04-22T15:27:58Z

 	if azureContext.Scope.Location != "" && locationAllowed(azureContext.Scope.Location, allowedLocations) {
-		return nil
+		// Location already set and valid — ensure AZURE_AI_DEPLOYMENTS_LOCATION is also set
+		return setEnvValue(ctx, azdClient, envName, "AZURE_AI_DEPLOYMENTS_LOCATION", azureContext.Scope.Location)


In the early-return path, azureContext.Scope.Location may have come from AZURE_AI_DEPLOYMENTS_LOCATION (via loadAzureContext). If AZURE_LOCATION is currently unset, this returns without seeding it, leaving the resource group location missing. Consider reading current env values and setting AZURE_LOCATION only when it is empty, while also ensuring AZURE_AI_DEPLOYMENTS_LOCATION is set when empty (without overwriting an existing, user-chosen RG location).

Copilot · 2026-04-22T15:27:59Z

+	// Set AI deployments location from the selected project.
+	// The project's location determines where AI models and resources are deployed.
+	previousLocation := azureContext.Scope.Location
 	azureContext.Scope.Location = selectedProject.Location
-	if err := setEnvValue(ctx, azdClient, envName, "AZURE_LOCATION", selectedProject.Location); err != nil {
-		return nil, fmt.Errorf("failed to set AZURE_LOCATION: %w", err)
+	if err := setEnvValue(
+		ctx, azdClient, envName, "AZURE_AI_DEPLOYMENTS_LOCATION", selectedProject.Location,
+	); err != nil {
+		return nil, fmt.Errorf("failed to set AZURE_AI_DEPLOYMENTS_LOCATION: %w", err)
+	}
+
+	// Seed AZURE_LOCATION (resource group location) if not already set.
+	// Default to co-locating with the project; user can override before deploying.
+	if previousLocation == "" {
+		if err := setEnvValue(ctx, azdClient, envName, "AZURE_LOCATION", selectedProject.Location); err != nil {
+			return nil, fmt.Errorf("failed to set AZURE_LOCATION: %w", err)
+		}


previousLocation := azureContext.Scope.Location is tracking the AI deployments location (per loadAzureContext), not whether AZURE_LOCATION (resource group location) is set. If an environment has AZURE_AI_DEPLOYMENTS_LOCATION set but AZURE_LOCATION unset, this block will skip seeding AZURE_LOCATION, leaving it missing. Consider checking the actual AZURE_LOCATION env value (e.g., via Environment().GetValue/GetValues) before deciding whether to set it.

Copilot · 2026-04-22T15:27:59Z

+	// Use AZURE_AI_DEPLOYMENTS_LOCATION for Scope.Location (used for model filtering).
+	// Fall back to AZURE_LOCATION for backward compatibility with older environments.
+	location := envValueMap["AZURE_AI_DEPLOYMENTS_LOCATION"]
+	if location == "" {
+		location = envValueMap["AZURE_LOCATION"]
+	}
+
 	return &azdext.AzureContext{
 		Scope: &azdext.AzureScope{
 			TenantId:       envValueMap["AZURE_TENANT_ID"],
 			SubscriptionId: envValueMap["AZURE_SUBSCRIPTION_ID"],
-			Location:       envValueMap["AZURE_LOCATION"],
+			Location:       location,


loadAzureContext now prefers AZURE_AI_DEPLOYMENTS_LOCATION over AZURE_LOCATION. This is behaviorally significant for model filtering and project selection; there don’t appear to be unit tests covering the precedence/fallback behavior. Consider adding tests for (1) AI var set, (2) only AZURE_LOCATION set (back-compat), and (3) neither set.

Copilot · 2026-04-22T15:27:59Z

@@ -98,7 +98,9 @@ func (a *modelSelector) updateEnvLocation(ctx context.Context, selectedLocation
 	}
 	a.azureContext.Scope.Location = selectedLocation

-	fmt.Println(output.WithSuccessFormat("Updated AZURE_LOCATION to '%s' in your azd environment.", selectedLocation))
+	fmt.Println(output.WithSuccessFormat(
+		"Updated AZURE_AI_DEPLOYMENTS_LOCATION to '%s' in your azd environment.", selectedLocation,
+	))


updateEnvLocation now updates AZURE_AI_DEPLOYMENTS_LOCATION instead of AZURE_LOCATION, and also mutates a.azureContext.Scope.Location. There are unit tests in this package but none covering this env update path; consider adding a test to verify the correct key is written and that the in-memory AzureContext is updated accordingly.

jongio

Sound approach for #7670 - splitting AI deployment location (AZURE_AI_DEPLOYMENTS_LOCATION) from resource group location (AZURE_LOCATION) is the right fix.

Two items beyond what the automated review already covers:

Warning message (line 755): The warning in ensureLocation says "The current AZURE_LOCATION '...' is not supported" but after this change, Scope.Location may hold the value from AZURE_AI_DEPLOYMENTS_LOCATION. A user who set only the AI var to an unsupported region would see a misleading reference to AZURE_LOCATION. Consider "The current location '%s' is not supported..." or similar generic wording.

init_from_code.go:549: The guard if a.azureContext.Scope.Location == "" protects a call to ensureLocation. Since loadAzureContext now prefers AZURE_AI_DEPLOYMENTS_LOCATION, this guard can be false (location appears set) when AZURE_LOCATION is actually unset. Same root cause as the ensureLocation early-return gap, different call site.

microsoft-github-policy-service · 2026-04-29T16:19:26Z

Hi @@therealjohn. Thank you for your interest in helping to improve the Azure Developer CLI experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

wbreza

Code Review Summary

Priority	Count
Medium	1
Low	1
Total	2

Assessment: Approve — the logic is correct and well-structured. Two suggestions below.

✅ What Looks Good

Clean fallback semantics in loadAzureContext — backward compatible with existing environments
Proper error propagation in ensureLocation with early return
Defensive AZURE_LOCATION seeding in selectFoundryProject avoids clobbering user's explicit region choice

wbreza · 2026-04-29T17:56:35Z

+	// Use AZURE_AI_DEPLOYMENTS_LOCATION for Scope.Location (used for model filtering).
+	// Fall back to AZURE_LOCATION for backward compatibility with older environments.
+	location := envValueMap["AZURE_AI_DEPLOYMENTS_LOCATION"]
+	if location == "" {


[Medium] New env var AZURE_AI_DEPLOYMENTS_LOCATION not documented

Repo standards require new environment variables to be added to cli/azd/docs/environment-variables.md. This variable has no entry in the canonical reference — users won't discover it except by reading extension source code.

Add an entry to the Core Azure Variables table:

| AZURE_AI_DEPLOYMENTS_LOCATION | The Azure region for AI model deployments. Falls back to AZURE_LOCATION if unset. |

wbreza · 2026-04-29T17:56:35Z

 	_, err := a.azdClient.Environment().SetValue(ctx, &azdext.SetEnvRequest{
 		EnvName: envName,
-		Key:     "AZURE_LOCATION",
+		Key:     "AZURE_AI_DEPLOYMENTS_LOCATION",


[Low] Magic string "AZURE_AI_DEPLOYMENTS_LOCATION" repeated 6+ times

This literal appears across both files with no compile-time protection against typos. Extract to a package-level constant for single-source-of-truth and IDE rename support:

const envKeyAIDeploymentsLocation = "AZURE_AI_DEPLOYMENTS_LOCATION"

microsoft-github-policy-service · 2026-05-12T19:39:48Z

Hi @@therealjohn. Thank you for your contribution. Since there hasn't been recent engagement, we're going to close this out. Feel free to respond with a comment containing "/reopen" if you'd like to continue working on these changes. Please be sure to use the command to reopen or remove the "no-recent-activity" label; otherwise, this is likely to be closed again with the next cleanup pass.

Introduce AZURE_AI_DEPLOYMENTS_LOCATION env var to decouple model/project deployment location from the resource group location (AZURE_LOCATION). When a user selects a model from a different region during init, only AZURE_AI_DEPLOYMENTS_LOCATION is updated, preserving AZURE_LOCATION for the resource group. This prevents provisioning failures when the Foundry project and resource group are in different regions. Fixes Azure#7670 Supersedes Azure#7873

…8321) * fix: separate model deployment location from resource group location Introduce AZURE_AI_DEPLOYMENTS_LOCATION env var to decouple model/project deployment location from the resource group location (AZURE_LOCATION). When a user selects a model from a different region during init, only AZURE_AI_DEPLOYMENTS_LOCATION is updated, preserving AZURE_LOCATION for the resource group. This prevents provisioning failures when the Foundry project and resource group are in different regions. Fixes #7670 Supersedes #7873 * Address review: defensive AZURE_LOCATION seed + updateEnvLocation test - ensureLocation fast-path now seeds AZURE_LOCATION when unset, preventing provisioning failures if only AZURE_AI_DEPLOYMENTS_LOCATION was configured. - Add TestUpdateEnvLocation covering env var persistence and azureContext update. --------- Co-authored-by: Jian Wu <wujia@microsoft.com>

Copilot AI review requested due to automatic review settings April 22, 2026 15:23

therealjohn requested review from JeffreyCA, hemarina, jongio, rajeshkamal5050, tg-msft, trangevi, trrwilson, vhvb1989, wbreza and weikanglim as code owners April 22, 2026 15:23

Copilot started reviewing on behalf of therealjohn April 22, 2026 15:24 View session

microsoft-github-policy-service Bot assigned therealjohn Apr 22, 2026

Copilot AI reviewed Apr 22, 2026

View reviewed changes

jongio reviewed Apr 22, 2026

View reviewed changes

microsoft-github-policy-service Bot added the no-recent-activity identity issues with no activity label Apr 29, 2026

wbreza approved these changes Apr 29, 2026

View reviewed changes

vhvb1989 approved these changes Apr 29, 2026

View reviewed changes

JeffreyCA added the ext-agents azure.ai.agents extension label May 5, 2026

microsoft-github-policy-service Bot closed this May 12, 2026

therealjohn reopened this May 22, 2026

therealjohn closed this May 22, 2026

v1212 mentioned this pull request May 22, 2026

fix: separate model deployment location from resource group location #8321

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix: deploy with separate locations for models and other foundry projects#7873

fix: deploy with separate locations for models and other foundry projects#7873
therealjohn wants to merge 1 commit into
Azure:mainfrom
therealjohn:fix-7670

therealjohn commented Apr 22, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

Copilot AI Apr 22, 2026

Uh oh!

jongio left a comment

Uh oh!

microsoft-github-policy-service Bot commented Apr 29, 2026

Uh oh!

wbreza left a comment

Uh oh!

wbreza Apr 29, 2026

Uh oh!

wbreza Apr 29, 2026

Uh oh!

microsoft-github-policy-service Bot commented May 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

Uh oh!

Conversation

therealjohn commented Apr 22, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 22, 2026

Choose a reason for hiding this comment

Uh oh!

jongio left a comment

Choose a reason for hiding this comment

Uh oh!

microsoft-github-policy-service Bot commented Apr 29, 2026

Uh oh!

wbreza left a comment

Choose a reason for hiding this comment

Code Review Summary

✅ What Looks Good

Uh oh!

wbreza Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

wbreza Apr 29, 2026

Choose a reason for hiding this comment

Uh oh!

microsoft-github-policy-service Bot commented May 12, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants