Skip to content

v3.1.0

Choose a tag to compare

View all tags
@placerda placerda released this 01 Jul 10:46
v3.1.0
8f0b81f
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

User and operator impact

Fresh deployments now consume AI Landing Zone v2.2.0, which flips the default resourceNamingMode from legacy to caf and derives every CAF token automatically (workload from a subscription/env/location hash, environment from AZURE_ENV_NAME, region from a built-in abbreviation map). Fresh Basic and Zero Trust provisions therefore produce Cloud Adoption Framework-aligned resource names out of the box (for example cosmos-<hash>-<env>-<region>-001), without requiring operators to set CAF_WORKLOAD_NAME, CAF_ENVIRONMENT_NAME, or CAF_REGION_NAME. Operators who still want the pre-v2.2.0 naming scheme can opt back in by setting RESOURCE_NAMING_MODE=legacy before azd provision.

Changed

  • AI Landing Zone Bicep module pin bumped to v2.2.0: manifest.json, .gitmodules, and the infra submodule HEAD are aligned on the CAF-default landing-zone release. This supersedes the interim v2.1.6 pin.
  • main.parameters.json aligned with the v2.2.0 CAF-default contract: resourceNamingMode now defaults to caf, and cafWorkloadName, cafEnvironmentName, and cafRegionName default to empty strings so the landing-zone bicep resolves them from AZURE_ENV_NAME, AZURE_LOCATION, and a subscription-scoped hash. Operators can still override every token via the same \ environment variables.

Fixed

  • Azure AI Foundry can be provisioned in a different region than the primary deployment: main.bicep now exposes an aiFoundryLocation parameter (wired from AZURE_AI_FOUNDRY_LOCATION) and routes both the AI Foundry account module and its capability host through it, so deployments with AZURE_LOCATION=<primary> and AZURE_AI_FOUNDRY_LOCATION=<foundry-region> no longer force the AI Foundry account into the primary region.
  • scripts/postProvision.ps1 is now CAF-naming aware: introduced an _resolveResource helper that queries az resource list per resource type (AI Foundry, Storage, Cosmos, Search, Key Vault, ACR, Container Apps Environment, Log Analytics, App Insights) and falls back to the legacy <prefix>-<resourceToken> derivation. Foundry project name is discovered via az cognitiveservices account list-projects; Cosmos DB name via az cosmosdb sql database list. Without this fix, post-provision failed with ResourceNotFound under the new resourceNamingMode=caf default. Legacy environments continue to work via the fallback.

Component versions

Component Version
gpt-rag-ui v2.3.13
gpt-rag-orchestrator v3.0.4
gpt-rag-ingestion v2.4.14
infra / AI Landing Zone v2.2.0

Validation

  • Fresh Basic (non-Zero-Trust) provision + deploy in Australia East with AI Foundry in East US 2, RETRIEVAL_BACKEND=foundry_iq, and FOUNDRY_IQ_PATTERN=searchIndex.
  • Post-provision resolver picked up all CAF-named resources; AI Foundry blocklist and RAI policy were created against the CAF-named account; AppConfig was populated with 103 keys; AI Search indexes plus the Foundry IQ knowledge source and knowledge base were created.
  • azd deploy --all succeeded; all three container apps became Healthy on --0000001 with 100% traffic.
  • Frontend was fronted by Container Apps Easy Auth (RedirectToLoginPage, v2 issuer).
  • az bicep build --file infra/main.bicep exited 0.
Assets 2
Loading