[Sprint 2] Extract stacks/data-ai/ — Cosmos DB + AI Foundry
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Refactor
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- azure, terraform
- Domain
- cloud, devops, infrastructure
Research direction
Start by comparing infra/terraform/main.tf with the requested files under infra/terraform/stacks/data-ai/. Run terraform state list | grep ai_foundry to enumerate AVM-managed resources, then review the state-migration and removed-block requirements. Done means both stacks plan with 0 changes, the 14 Cosmos containers remain intact, and the private endpoint and AI Foundry outputs work independently.
Written by the indexing model from the issue text.
Description
Summary
Extract Cosmos DB (account, database, containers, private endpoint) and AI Foundry (AVM module) from infra/terraform/main.tf into a new stacked root module at infra/terraform/stacks/data-ai/.
Parent epic: #119
Business Context
The AI Foundry AVM module (Cognitive Services + Hub + Project + 2 model deployments) can take 20–30 minutes on first deployment. Cosmos DB provisioning with private endpoint adds another ~5 min. Currently these compete with ACA app creation for control-plane quota in the same terraform apply. Isolating them allows:
- Parallel provisioning with ACA apps (both depend only on foundation)
- Independent retry on Foundry 409
RequestConflicterrors (#117) - Reduced blast radius — Foundry failure doesn't block ACA app creation
Scope
Resources to extract
| Current address | Notes |
|---|---|
azurerm_cosmosdb_account.main |
Includes public_network_access = "Disabled" |
azurerm_cosmosdb_sql_database.main |
|
azurerm_cosmosdb_sql_container.containers (for_each × 14) |
|
azurerm_private_endpoint.cosmos |
References foundation VNet subnet |
module.ai_foundry |
AVM module Azure/avm-ptn-aiml-ai-foundry/azurerm v0.10.0 — creates ~8 child resources internally |
Stay in foundation (shared VNet resources):
azurerm_private_dns_zone.cosmosazurerm_private_dns_zone_virtual_network_link.cosmos
Files to create
infra/terraform/stacks/data-ai/main.tfinfra/terraform/stacks/data-ai/variables.tfinfra/terraform/stacks/data-ai/outputs.tf—cosmos_endpoint,cosmos_database_name,ai_foundry_id,project_endpoint,model_deployment_name,model_reasoning_deployment,ai_services_endpointinfra/terraform/stacks/data-ai/providers.tf
State migration
High risk — the AI Foundry AVM module manages ~8 internal resources. Migration steps:
terraform state list | grep ai_foundryto enumerate all AVM-managed addressesterraform state mveach resource from monolith → data-ai state- Do the same for all Cosmos resources + private endpoint
- Validate with
terraform planon both stacks — expect 0 changes
Input Variables
| Variable | Source |
|---|---|
environment |
Workflow env |
name_prefix / normalized_prefix |
Foundation output or computed |
resource_group_name / resource_group_id |
Foundation output |
location / foundry_location |
Foundation output / variable |
cosmos_private_endpoint_subnet_id |
Foundation output |
cosmos_private_dns_zone_ids |
Foundation output (list) |
storage_account_id |
Foundation output |
cosmos_containers |
Variable (same map as current) |
random_suffix |
Foundation output |
Acceptance Criteria
-
terraform planonstacks/data-ai/shows 0 changes after state migration -
terraform planon foundation shows 0 changes after resource removal - Cosmos DB private endpoint resolves correctly through foundation VNet
- AI Foundry model deployments are accessible from ACA apps
- Cosmos containers match production schema (14 containers)
- Stack is independently
terraform plan-able for drift detection
Risk
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Cosmos data loss during state move | Low | Critical | removed block with destroy = false; verify plan before apply; backup state file |
| AVM module state fragmentation | Medium | Medium | Enumerate all child resources via terraform state list; move atomically |
| Private endpoint loses DNS resolution | Low | High | DNS zone stays in foundation; only the PE resource moves |
- Dominant language
- Python
- Stars
- 17
- Forks
- 8
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure-Samples/tutor
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
Azure-Samples/tutor#230 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Azure-Samples/tutor#229 · 1 comment ·
-
frontend priority:P2 type:tech-debt
Difficulty 5/5 Over a week Newbie friendliness 35/100
Azure-Samples/tutor#224 · 3 comments ·
-
component:ci-cd frontend priority:P1 type:tech-debt
Difficulty 5/5 Over a week Newbie friendliness 35/100
Azure-Samples/tutor#223 · 2 comments ·
-
frontend priority:P1 type:feature
Difficulty 5/5 Over a week Newbie friendliness 30/100
Azure-Samples/tutor#222 · 1 comment ·
All issues in Azure-Samples/tutor
Similar issues
-
documentation help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
simonw/sqlite-utils#872 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100