You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Epic: Provisioning Providers in the AZD Extension Framework
Problem Statement
Today, azd supports only two built-in provisioning providers ΓÇö Bicep and Terraform ΓÇö hardcoded in pkg/azd/default.go. There is no extensibility mechanism for third-party or first-party extensions to supply custom provisioning providers (e.g., Pulumi, CloudFormation, scripts, CDK, custom IaC tools).
The extension framework already supports two analogous extensibility points (Custom Service Targets and Custom Framework Services) using a proven pattern: proto definition → MessageBroker → ExtensionHost fluent API → server-side gRPC handler → core-side adapter → IoC registration. This epic extends that pattern to provisioning providers.
User Personas
Extension Author (Primary)
Who: A developer building an azd extension that provides an alternative IaC tool (e.g., Pulumi provider, script-based provisioner, CDK bridge). Goals: Register a custom provisioning provider via the ExtensionHost API, implement a well-defined Go interface, have azd seamlessly call their provider for provision, deploy, destroy, and state commands. Pain Points: Currently must fork azd or use workarounds. No documented, supported API for custom provisioners.
End User (Secondary)
Who: A developer using azd with azure.yaml who installs an extension providing a custom provisioner. Goals: Set infra.provider: myprov in azure.yaml, run azd provision, and have the extension's provisioner execute transparently. Pain Points: Limited to Bicep or Terraform. No way to use other IaC tools through azd.
Platform Team (Tertiary)
Who: Azure teams building first-party extensions for new IaC workflows (e.g., deployment scripts, CDK, ARM template generators). Goals: Leverage the same extensibility framework used for service targets and framework services.
Single provider per registration: Unlike service targets (which use ComponentManager for per-service instances), provisioning providers are project-level singletons. One provider per WithProvisioningProvider() call.
Provider name as IoC key: The name from registration becomes the IoC named key, matching azure.yaml's infra.provider value
Progress streaming: Deploy, Preview, and Destroy support in-band progress messages via the MessageBroker
Config pass-through: Options.Config map[string]any allows arbitrary extension-specific config from azure.yaml
Relaxed validation: ParseProvider() must accept any string (not just built-in provider names)
graph TD
A[#7466 Proto Definition] --> B[#7467 Codegen]
B --> C[#7468 Envelope]
B --> D[#7469 Interface]
B --> E[#7471 AzdClient]
B --> F[#7473 Core Adapter]
C --> G[#7470 Manager]
D --> G
E --> G
C --> H[#7474 gRPC Service]
F --> H
I[#7475 Capability] --> H
G --> J[#7472 ExtensionHost]
H --> K[#7477 IoC Wiring]
I --> L[#7476 Middleware]
J --> M[#7479 Demo Extension]
K --> M
L --> M
N[#7478 Validation] --> M
C --> O[#7480 Unit Tests]
G --> O
F --> O
H --> O
N --> O
M --> P[#7481 Integration Tests]
O --> P
Loading
Risks
Risk
Impact
Mitigation
Proto schema changes after initial implementation
High ΓÇö affects all layers
Design proto carefully upfront; review with team before implementing
Epic: Provisioning Providers in the AZD Extension Framework
Problem Statement
Today, azd supports only two built-in provisioning providers ΓÇö Bicep and Terraform ΓÇö hardcoded in
pkg/azd/default.go. There is no extensibility mechanism for third-party or first-party extensions to supply custom provisioning providers (e.g., Pulumi, CloudFormation, scripts, CDK, custom IaC tools).The extension framework already supports two analogous extensibility points (Custom Service Targets and Custom Framework Services) using a proven pattern: proto definition → MessageBroker → ExtensionHost fluent API → server-side gRPC handler → core-side adapter → IoC registration. This epic extends that pattern to provisioning providers.
User Personas
Extension Author (Primary)
Who: A developer building an azd extension that provides an alternative IaC tool (e.g., Pulumi provider, script-based provisioner, CDK bridge).
Goals: Register a custom provisioning provider via the ExtensionHost API, implement a well-defined Go interface, have azd seamlessly call their provider for
provision,deploy,destroy, andstatecommands.Pain Points: Currently must fork azd or use workarounds. No documented, supported API for custom provisioners.
End User (Secondary)
Who: A developer using azd with
azure.yamlwho installs an extension providing a custom provisioner.Goals: Set
infra.provider: myprovinazure.yaml, runazd provision, and have the extension's provisioner execute transparently.Pain Points: Limited to Bicep or Terraform. No way to use other IaC tools through azd.
Platform Team (Tertiary)
Who: Azure teams building first-party extensions for new IaC workflows (e.g., deployment scripts, CDK, ARM template generators).
Goals: Leverage the same extensibility framework used for service targets and framework services.
Architecture
Key Design Decisions
azdextension framework #5381WithProvisioningProvider()call.azure.yaml'sinfra.providervalueOptions.Config map[string]anyallows arbitrary extension-specific config fromazure.yamlParseProvider()must accept any string (not just built-in provider names)Work Items
Layer 1: Foundation (Must complete first)
Layer 2: Core Components (Can parallelize after Layer 1)
Layer 3: Managers & Adapters (Depends on Layer 2)
Layer 4: Integration (Depends on Layer 3)
Layer 5: Validation (Depends on everything)
Follow-up Items
Dependency Graph
graph TD A[#7466 Proto Definition] --> B[#7467 Codegen] B --> C[#7468 Envelope] B --> D[#7469 Interface] B --> E[#7471 AzdClient] B --> F[#7473 Core Adapter] C --> G[#7470 Manager] D --> G E --> G C --> H[#7474 gRPC Service] F --> H I[#7475 Capability] --> H G --> J[#7472 ExtensionHost] H --> K[#7477 IoC Wiring] I --> L[#7476 Middleware] J --> M[#7479 Demo Extension] K --> M L --> M N[#7478 Validation] --> M C --> O[#7480 Unit Tests] G --> O F --> O H --> O N --> O M --> P[#7481 Integration Tests] O --> PRisks
User Flows
Extension Author: Developing a Custom Provisioning Provider
extension.yamldeclaringprovisioning-providercapabilityazdext.ProvisioningProviderinterface (7 methods)host.WithProvisioningProvider("myprov", factory).Run(ctx)End User: Using a Custom Provisioning Provider
azd ext install publisher/myprov-extensionazure.yaml:infra: { provider: myprov, config: { ... } }azd provision— azd starts extension, extension registers providermyprovfrom IoC →ExternalProvisioningProviderReferences
azdextension framework #5381 (old POC ΓÇö do NOT follow this approach)service_target.proto/service_target_manager.go/service_target_external.go(model to follow)framework_service.proto/framework_service_manager.go(another model)pkg/grpcbroker/message_broker.go(core infrastructure)