Direct module support for Recipes#11876
Conversation
Signed-off-by: Reshma Abdul Rahim <61033581+Reshrahim@users.noreply.github.com>
Radius functional test overviewClick here to see the test run details
Test Status⌛ Building Radius and pushing container images for functional tests... |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #11876 +/- ##
==========================================
+ Coverage 51.47% 51.69% +0.21%
==========================================
Files 699 725 +26
Lines 44130 45595 +1465
==========================================
+ Hits 22718 23572 +854
- Misses 19251 19798 +547
- Partials 2161 2225 +64 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| @@ -0,0 +1,207 @@ | |||
| # Feature Specification: Direct Module Support | |||
There was a problem hiding this comment.
I experimented with the Spec Kit approach and decided it was more effective to follow the template in eng/design-notes/templates/feature-spec-template.md. I would give Copilot the following prompt:
Combine spec.md, research.md (if appropriate), quickstart.md, and data-model.md into eng/design-notes/recipdes/2026-05-direct-recipe-modules.md. Only put feature related details in this document and omit implementation details. Create the doc according to eng/design-notes/templates/feature-spec-template.md.
| ### User Story 4 — Private Module Authentication (Priority: P2) | ||
|
|
||
| As a platform engineer, I want to use modules hosted in private registries, private Git repositories, or private OCI registries as recipes, authenticating with credentials configured through the existing secret store. | ||
|
|
||
| **Why this priority**: Enterprise teams host modules in private repositories. Without authentication support, direct module support is limited to public modules. | ||
|
|
||
| **Independent Test**: Link a recipe pointing to a private Terraform registry module or Git repository, configure credentials via the existing secret mechanism, deploy, and verify the module is fetched successfully. | ||
|
|
There was a problem hiding this comment.
I think this can be removed.
There was a problem hiding this comment.
Is this covered in the extensibility world already ?
Signed-off-by: Reshma Abdul Rahim <reshmarahim.abdul@microsoft.com>
|
|
||
| - Enable platform engineers to leverage community owned Terraform registry modules and Azure Verified Modules directly as Radius Recipes | ||
| - Eliminate the need to write a Recipe wrapper, publish, and maintain these Recipes separately from the underlying module | ||
| - Eliminate the need for Radius to maintain a catalog of wrapped Recipes in the `resource-types-contrib` repository thus reducing maintenance overhead and surface area for supply chain attacks |
There was a problem hiding this comment.
I'm not sure this approach reduces overhead for supply chain attacks
|
|
||
| ### Scenario 1: Terraform Registry Module | ||
|
|
||
| A platform engineer sets `location` to a Terraform registry path (e.g., `terraform-aws-modules/rds/aws`) and the system deploys it by automatically resolving developer set properties via `context` as Terraform input variables, and mapping module outputs to resource properties via the `outputs` field. |
There was a problem hiding this comment.
shouldnt this be a uri like terraform.io/aws/rds/aws?
There was a problem hiding this comment.
should there be a version here?
| recipes: { | ||
| 'Radius.Data/mySqlDatabases': { | ||
| kind: 'terraform' | ||
| location: 'terraform-aws-modules/rds/aws' |
There was a problem hiding this comment.
should we have a type field? reference
|
|
||
| ### Feature 1: Direct Module Execution | ||
|
|
||
| Use any standard Bicep or Terraform module directly as a recipe by pointing `location` at the module source. The system automatically detects that the module is not a Radius wrapper (no `context` variable), downloads it, and executes it through the existing driver — no wrapper needed. |
There was a problem hiding this comment.
is location overloaded? we use it for azure location too
|
|
||
| ### Feature 2: Template Expression Resolution | ||
|
|
||
| A `{{context.*}}` expression system that resolves Radius application runtime context values into recipe parameters at deploy time. Supports resource metadata, application/environment info, Kubernetes runtime, Azure, and AWS provider context. Includes single-level ternary expressions for conditional value mapping. |
There was a problem hiding this comment.
is there a scenario where the backing module will need information from context that can't be passed via a param?
|
|
||
| ### Feature 3: Output Mapping | ||
|
|
||
| An `outputs` field on `RecipeDefinition` that maps module output names to resource property names. Provides a stable property interface for resource consumers regardless of the underlying module's output naming. Sensitive outputs are automatically routed to the Secrets map. |
There was a problem hiding this comment.
could we add an example for the secrets?
| } | ||
| } | ||
| } | ||
| ``` |
| } | ||
| } | ||
| outputs: { | ||
| host: 'fqdn' |
There was a problem hiding this comment.
what are these outputs? why are they set?
| kind: 'terraform' | ||
| location: 'terraform-aws-modules/rds/aws' | ||
| parameters: { | ||
| identifier: '{{context.resource.name}}' |
There was a problem hiding this comment.
this might be a technical limitation here, I don't know how this will work
| recipes: { | ||
| 'Radius.Data/mySqlDatabases': { | ||
| kind: 'terraform' | ||
| location: 'terraform-aws-modules/rds/aws' |
There was a problem hiding this comment.
one thing to think about - I think currently aws terraform modules that specify an aws provider will fail because we try to set the provider ourselves. we need to fix this first
3 participants
This pull request adds a comprehensive design note describing the "Direct Recipe Modules" feature for Radius. The document outlines how platform engineers can use standard Bicep or Terraform modules directly as Radius Recipes, removing the need for custom wrappers and reducing maintenance overhead. It covers user personas, challenges, desired outcomes, implementation details, and usage examples.
Key documentation additions:
Feature overview and motivation
locationfield of a recipe, eliminating the need for Radius-specific wrappers and simplifying adoption and maintenance.Core features and scenarios
Risks, dependencies, and limitations
User experience and implementation details
Please explain the changes you've made.
Type of change
Fixes: #issue_number
Contributor checklist
Please verify that the PR meets the following requirements, where applicable:
eng/design-notes/in this repository, if new APIs are being introduced.