Feature spec: compute extensibility user experience #96
Conversation
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
… 2.5 Pro assisted in VSCode) Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
| - **Bicep/Terraform Capabilities and Limitations**: The feasibility of implementing all necessary provisioning logic (currently in Go for Kubernetes) within Bicep or Terraform recipes. | ||
| - Risk: Some complex logic might be difficult or impossible to replicate. | ||
| - Mitigation: Early Proof of Concept (POC) for Kubernetes provisioning in Bicep/Terraform. Implement ACI provisioning first as a less complex target to identify limitations. Consider Terraform if Bicep has significant gaps for certain platforms. | ||
| - **Radius Application Graph Integrity**: Ensuring that recipes can correctly define and maintain relationships and connections between resources (e.g., `containers.connections`) as the current system does. |
There was a problem hiding this comment.
We've talked about this a lot and I cover this in my design, if we don't move forward with my design we can still move forward with the nested types concept and using connections which would expressly create those relationships for the app graph on behalf of the recipe authors.
There was a problem hiding this comment.
Additionally I'll be authoring a design on a new test framework for type/recipe combinations that check whether the contract is satisfied by recipe execution.
|
|
||
| ### Non-goals (out of scope) | ||
| <!-- What are we explicitly not trying to accomplish? --> | ||
| - Running the Radius control plane on a non-Kubernetes platform. |
There was a problem hiding this comment.
This is out of scope for now or forever?
There was a problem hiding this comment.
out of scope for now, added a link to the roadmap item here.
| <!-- What big questions must we answer in order to clarify our plan for this scenario. When and how do you plan to answer those questions (prototype feature x, user research, competitive research, etc.) --> | ||
| - **Assumption**: All essential provisioning logic currently in Radius's Go code for Kubernetes (for containers, gateways, secret stores) can be effectively replicated using Bicep or Terraform recipes. | ||
| - Validation: POC implementation of Kubernetes recipes for core functionalities. | ||
| - **Assumption**: Recipes can reliably output the necessary information for Radius to construct and maintain the application graph, including resource connections. |
There was a problem hiding this comment.
This works the other way around, AppCoreRP constructs the graph including connections and then provides recipe inputs, so I don't think there will be any risk.
| - Validation: Test recipe deployments and inspect the resulting Radius graph. | ||
| - **Question**: What is the most effective way for recipes to declare their input parameters and output properties to ensure consistency and enable validation? | ||
| - Exploration: Define a clear contract for recipes, potentially using a schema or metadata definition that can be validated. | ||
| - **Question**: How can platform engineers easily test and debug their custom recipes before registering them in a live environment? |
There was a problem hiding this comment.
I will address this in the type/recipe testing framework design
| … --> | ||
| #### Setting up and deploying an application to a Radius environment using existing Recipes for core types: | ||
|
|
||
| 1. **Discover existing Recipes**: |
There was a problem hiding this comment.
Do people browse OCI registries? I believe we're missing an opportunity here because usually they find things in some other way (depending on the package framework) then the OCI registry is the source for install. Dockerhub is an example where it does both, but the search/browse framework is not part of the registry inherently. You can't go to ghcr.io in your browser for instance.
There was a problem hiding this comment.
We can leverage something like an Artifact Hub -https://artifacthub.io/ to discover Recipes
There was a problem hiding this comment.
yes, good points, but let's keep Recipe discoverability separate from this feature spec.
| } | ||
| } | ||
| // This container requests confidential compute | ||
| extensions: [ |
There was a problem hiding this comment.
Do we support extensions on UDTs? Wouldn't these be additional optional properties consumed as recipe inputs instead?
| 1. **Configure Environment-Specific Recipe Parameters (Optional)**: | ||
| * If recipes have parameters that need to be set globally for an environment, configure them using `rad recipe update` or during registration. | ||
|
|
||
| #### Packaging and Registering a "Recipe Pack" for an Environment: |
There was a problem hiding this comment.
This is a fantastic implementation, I like that version is already included.
| <!-- One or two sentence summary --> | ||
| Implement a system for packaging and versioning sets of related recipes (Recipe Packs) to simplify distribution and management. This includes defining a clear structure for Recipe Packs and providing CLI commands for creating, updating, and applying them. Default Recipes for Kubernetes and ACI will be provided by Radius as part of the initial Recipe Packs. | ||
|
|
||
| ### Feature 5: CLI Enhancements for Recipe Management (as necessary) |
There was a problem hiding this comment.
I'd like to at least see a CLI change that takes the recipe pack manifest as input and will register all of them in one command. It would be great to see this for types as well.
There was a problem hiding this comment.
Agreed, a rad environment update my-env --recipe-pack ./recipe-pack.yaml command is proposed in the detailed user scenarios section.
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
|
|
||
| ### Non-goals (out of scope) | ||
| <!-- What are we explicitly not trying to accomplish? --> | ||
| - Running the Radius control plane on a non-Kubernetes platform. |
There was a problem hiding this comment.
Does this mean that with extensibility and core types as UDTs we shouldn't expect to be able to host UCP in a different platform?
|
|
||
| ### Positive user outcome | ||
| <!-- What is the positive outcome for the user if we deliver this, i.e. what is the value proposition for the user? Remember, this is user-centric. --> | ||
| As a platform engineer, I can confidently adopt Radius across my organization, knowing I can extend its capabilities to support any compute platform, secret store, or gateway my teams require, without waiting for built-in support or modifying Radius core. I can register, customize, and share recipes that define how Radius provisions these resources, ensuring consistency with our application definitions while maintaining flexibility in our infrastructure choices and adhering to organizational standards. This empowers my development teams to leverage Radius benefits regardless of the underlying infrastructure. |
There was a problem hiding this comment.
We are talking about containers, secret stores, and gateways a lot. Are these the main resource types that we are focusing on? Why are we not talking about other core resource types?
There was a problem hiding this comment.
Good point, we should include volumes, Will T said extenders are out of scope which I agree as I believe they'd just be replaced by new types/recipes.
There was a problem hiding this comment.
yup, added the inclustion of volume resources too now.
| A platform engineer customizes the default Kubernetes recipes for `Applications.Core/containers@2025-05-01-preview` (and similarly for `gateways` and `secretStores`) to align with company-specific infrastructure policies, such as adding mandatory security sidecars, custom labels for cost tracking, or integrating with internal monitoring systems, by modifying the recipe and re-registering it. | ||
|
|
||
| ### Scenario 3: Extend Radius to a new, unsupported platform | ||
| A platform engineer creates new Bicep or Terraform recipes to enable Radius to deploy `Applications.Core/containers@2025-05-01-preview` to AWS Fargate, `Applications.Core/gateways@2025-05-01-preview` to an AWS Application Load Balancer, and `Applications.Core/secretStores@2025-05-01-preview` to AWS Secrets Manager. They then register these recipes in their Radius environment. |
There was a problem hiding this comment.
If we could also build a library of core types, custom resource types, and extensibility types that the users would be able to use, that would be amazing for the community.
If someone builds the extensibility recipe to deploy to AWS Fargate and if I can see that and use that, I wouldn't need to write it from scratch.
I guess that would be huge for Radius.
There was a problem hiding this comment.
Is it possible to extend the recipe without creating full recipe but overriding certain parameters?
There was a problem hiding this comment.
Is it possible to extend the recipe without creating full recipe but overriding certain parameters?
no, but I've created a feature request to track this separately.
radius-project/radius#9820
| - Mitigation: Early Proof of Concept (POC) for Kubernetes provisioning in Bicep/Terraform. Implement ACI provisioning first as a less complex target to identify limitations. Consider Terraform if Bicep has significant gaps for certain platforms. | ||
| - **Radius Application Graph Integrity**: Ensuring that recipes can correctly define and maintain relationships and connections between resources (e.g., `containers.connections`) as the current system does. | ||
| - Risk: Recipes might not fully capture or might incorrectly represent resource relationships, leading to broken application deployments or incorrect graph data. | ||
| - Mitigation: Design and provide reusable Bicep/Terraform modules or clear patterns for recipes to declare outputs that contribute to the Radius graph. |
There was a problem hiding this comment.
I think users who think that the Radius graph is very important for them will pay attention to the outputs in the recipes.
Not sure if this is doable but we may have a validator that enforces some sort of outputs in the user recipes. That tool can be added to the CI/CD pipelines (or can be used locally) and may check for the validity of recipes and their outputs specifically.
| - Mitigation: Provide versioned resource types (e.g., `@2025-05-01-preview`), detailed migration guides, and potentially migration tooling. | ||
| - **Recipe Validation and Debugging**: Lack of strong, compile-time typing for recipes means invalid recipes might only be caught at registration or deployment time. | ||
| - Risk: Poor user experience due to difficult-to-debug deployment failures. | ||
| - Mitigation: Implement robust validation checks upon recipe registration (schema, parameters, outputs). Enhance CLI tooling for local recipe validation and testing. |
There was a problem hiding this comment.
I agree! We need to build this tool.
| - Validation: Test recipe deployments and inspect the resulting Radius graph. | ||
| - **Question**: What is the most effective way for recipes to declare their input parameters and output properties to ensure consistency and enable validation? | ||
| - Exploration: Define a clear contract for recipes, potentially using a schema or metadata definition that can be validated. | ||
| - **Question**: How can platform engineers easily test and debug their custom recipes before registering them in a live environment? |
There was a problem hiding this comment.
Do we mean deploying the resource that the recipe defines locally? We can have a make command for this that would spin up a local cluster and deploys the recipe. Not sure what we can do for cloud resources though.
There was a problem hiding this comment.
yeah, I think locally is a good start, sounds like @sylvainsf has this on his radar.
|
|
||
| ## Details of user problem | ||
| <!-- <Write this in first person. You basically want to summarize what “I” as a user am trying to accomplish, why the current experience is a problem and the impact it has on me, my team, my work and or biz, etc…. i.e. “When I try to do x aspect of cloud native app development, I have the following challenges / issues….<details>. Those issues result in <negative impact those challenges / issues have on my work and or business.> --> | ||
| When I, as a platform engineer, try to use Radius to deploy and manage applications across my organization, I face significant hurdles if our infrastructure strategy involves more than just Kubernetes. For example, if a development team wants to deploy a service to AWS Elastic Container Service (ECS) for cost or simplicity, or if we need to integrate with a managed cloud gateway service instead of the default Radius gateway on Kubernetes, I can't easily make Radius do this. I'm forced to tell my teams they can only use Radius for Kubernetes, or I have to build and maintain complex workarounds outside of Radius. This means either Radius doesn't fit our diverse needs, or I'm stuck maintaining a custom version of Radius or else needing to contribute core code changes upstream in to Radius, which is a huge operational burden and makes upgrades very risky. These limitations prevent us from fully leveraging Radius as a unified application platform across our varied infrastructure. |
There was a problem hiding this comment.
Great explanation of the problem. As I mentioned above, if we can also provide a very rich library, it would make things very easy for development teams.
We should also think about the possibility of extending an existing extensibility recipe. Let's say User/Company X developed deploying to ECS and published it to the library. Now, User/Company Y wants to use it but needs to add more functionality. We can have a capability of extends.
There was a problem hiding this comment.
This is a great idea, because then recipe authors don't have to merge upstream changes though they'd still have to test for breaking changes.
There was a problem hiding this comment.
Versioning may also work here. Users can extend a specific version of the recipe.
There was a problem hiding this comment.
I've created a feature request for this @ytimocin , good suggestion!
radius-project/radius#9820
|
|
||
| #### Packaging and Registering a "Recipe Pack" for an Environment: | ||
|
|
||
| 1. **Define a Recipe Pack**: |
There was a problem hiding this comment.
This would also be very helpful in the path to become more extensible.
| } | ||
| } | ||
| - providers: { | ||
| - // provider configurations no longer hard-coded here |
There was a problem hiding this comment.
Are we saying we will add info such as subscription and respurce grpup to the bicep recipe itself?
There was a problem hiding this comment.
We already have a requirement from some users that we will need to move those to the environment
There was a problem hiding this comment.
On second thought, this shouldn't be encoded in the recipe. We can keep providers as is for now.
| * Once the Recipe Pack is registered, the environment is configured with all the specified recipes for the core UDTs. | ||
| * When applications are deployed to this environment, Radius automatically uses the corresponding recipes from the pack to provision `Applications.Core/containers@2025-05-01-preview`, `Applications.Core/gateways@2025-05-01-preview`, and `Applications.Core/secretStores@2025-05-01-preview` resources. | ||
| 1. **Manage and Update Recipe Packs**: | ||
| * Platform engineers can update the Recipe Pack manifest (e.g., point to new recipe versions, change default parameters) and re-register it. The CLI could offer options to overwrite existing registrations or manage versions of the pack within the environment. |
There was a problem hiding this comment.
We need to design/review/implement recipe versioning. Will that be a prerequisite before we work on recipe packs?
There was a problem hiding this comment.
I think Recipes versioning will be a separate feature that we don't need to implement as a part of Recipe Packs. However, we should include versioning in scope for the implementation of Recipe Packs from the get go, even if the underlying Recipes packaged within the Pack don't support versioning yet.
Clarified this in the goals/non-goals
| - } | ||
| ] | ||
| // This container requests confidential compute | ||
| + runtimes: { |
There was a problem hiding this comment.
Should the confidential compute property be part of the ACI-specific recipe? Or is this an interim case while we look at Radius supporting conf containers?
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
|
|
||
| This scenario highlights that the application definition remains consistent. The underlying infrastructure and specific compute capabilities (standard vs. confidential) are determined by the recipes configured in the target Radius environment, allowing for flexible deployment to diverse compute platforms without altering the core application logic or Bicep code. | ||
|
|
||
| #### Creating and registering custom Recipes for core types: |
There was a problem hiding this comment.
does this mean that we would allow end users to use their own core types (containers, gateways, secretstores) and disable ours?
There was a problem hiding this comment.
Correct, or rather, users may use any recipes to instantiate any of the core types, OR they (platform engs) may register their own versions of the core types that will also be instantiated using corresponding Recipes.
| 2. **Discover/Create Recipes**: | ||
| * Find community-provided recipes for desired platforms (e.g., ACI, AWS Fargate) from an OCI registry or Radius documentation. | ||
| * Or, create custom Bicep/Terraform recipes for `Applications.Core/containers@2025-05-01-preview`, `Applications.Core/gateways@2025-05-01-preview`, and `Applications.Core/secretStores@2025-05-01-preview` to target a specific platform or customize existing behavior. | ||
| 3. **Register Recipes for Core Types**: |
There was a problem hiding this comment.
Is there a way to constraint certain app files to be used against only certain recipe? Example: App with confidential container property set to true, should be allowed only on confidential recipe.
There was a problem hiding this comment.
Not currently, we discussed this as well as the ability to only allow certain apps to use certain options/properties in a recipe.
|
|
||
| #### Packaging and Registering a "Recipe Pack" for an Environment: | ||
|
|
||
| 1. **Define a Recipe Pack**: |
There was a problem hiding this comment.
Why are recipe packs needed for extensibility?
There was a problem hiding this comment.
The idea is that users need a convenient way to register recipes in bulk for specific platforms (e.g. registering the pack for ACI instead of knowing about and having to register individual recipes for ACI, Azure gateway, Key Vault, Azure Volumes, etc. that are needed to deploy to ACI)
|
|
||
| ## Topic Summary | ||
| <!-- A paragraph or two to summarize the topic area. Just define it in summary form so we all know what it is. --> | ||
| Radius will be enhanced to support multiple compute platforms, secret stores, and gateway resources through a recipe-based extensibility model. This approach decouples Radius's core logic from platform-specific provisioning code. Core resource types (`containers`, `gateways`, and `secretStores`) will be implemented as User-Defined Types (UDTs) and will allow platform engineers to register Bicep or Terraform recipes for them. Radius will provide default recipes for Kubernetes and Azure Container Instances (ACI), but platform engineers can use, modify, or replace these to customize how Radius provisions resources to different environments, or to add support for entirely new platforms without requiring changes to Radius core. |
There was a problem hiding this comment.
Shouldn't core resource types include volumes?
There was a problem hiding this comment.
yes, it should. i'll add it.
| A platform engineer customizes the default Kubernetes recipes for `Applications.Core/containers@2025-05-01-preview` (and similarly for `gateways` and `secretStores`) to align with company-specific infrastructure policies, such as adding mandatory security sidecars, custom labels for cost tracking, or integrating with internal monitoring systems, by modifying the recipe and re-registering it. | ||
|
|
||
| ### Scenario 3: Extend Radius to a new, unsupported platform | ||
| A platform engineer creates new Bicep or Terraform recipes to enable Radius to deploy `Applications.Core/containers@2025-05-01-preview` to AWS Fargate, `Applications.Core/gateways@2025-05-01-preview` to an AWS Application Load Balancer, and `Applications.Core/secretStores@2025-05-01-preview` to AWS Secrets Manager. They then register these recipes in their Radius environment. |
There was a problem hiding this comment.
| A platform engineer creates new Bicep or Terraform recipes to enable Radius to deploy `Applications.Core/containers@2025-05-01-preview` to AWS Fargate, `Applications.Core/gateways@2025-05-01-preview` to an AWS Application Load Balancer, and `Applications.Core/secretStores@2025-05-01-preview` to AWS Secrets Manager. They then register these recipes in their Radius environment. | |
| A platform engineer creates new Bicep or Terraform recipes to enable Radius to deploy `Applications.Core/containers@2025-05-01-preview` to AWS Elastic Container Service (ECS), `Applications.Core/gateways@2025-05-01-preview` to an AWS Application Load Balancer, and `Applications.Core/secretStores@2025-05-01-preview` to AWS Secrets Manager. They then register these recipes in their Radius environment. |
There was a problem hiding this comment.
Fargate is just a compute option for ECS. Not the platform.
| When I, as a platform engineer, try to use Radius to deploy and manage applications across my organization, I face significant hurdles if our infrastructure strategy involves more than just Kubernetes. For example, if a development team wants to deploy a service to AWS Elastic Container Service (ECS) for cost or simplicity, or if we need to integrate with a managed cloud gateway service instead of the default Radius gateway on Kubernetes, I can't easily make Radius do this. I'm forced to tell my teams they can only use Radius for Kubernetes, or I have to build and maintain complex workarounds outside of Radius. This means either Radius doesn't fit our diverse needs, or I'm stuck maintaining a custom version of Radius or else needing to contribute core code changes upstream in to Radius, which is a huge operational burden and makes upgrades very risky. These limitations prevent us from fully leveraging Radius as a unified application platform across our varied infrastructure. | ||
|
|
||
| ## Desired user experience outcome | ||
| <!-- <Write this as an “I statement” that expresses the new capability from user perspective … i.e. After this scenario is implemented “I can do, x, y, z, steps in cloud native app developer and seamlessly etc... As a result <summarize positive impact on my work / business> --> |
There was a problem hiding this comment.
Azure Container Instances, AWS Fargate, or a future platform
Should be serverless container platforms including Azure Container Instances, Azure Container Apps, AWS ECS, Google CloudRun, and functions platforms including AWS Lambda, Azure Functions, and Google Cloud Functions.
There was a problem hiding this comment.
I wouldn't re-use the container resource for functions, we should consider publishing a new core type of function.
| } | ||
| } | ||
| } | ||
| - providers: { |
There was a problem hiding this comment.
The provider stores the AWS and Azure details that get past to the recipe context right? https://docs.radapp.io/reference/context-schema/#environment So we'll need the AWS account and region, and Azure subscription and resource group in the environment somewhere.
There was a problem hiding this comment.
Yes, good point, this shouldn't be encoded in the recipe. We can keep providers in the environment as is for now.
| * The platform engineer configures `std-env` with recipes for `Applications.Core/containers@2025-05-01-preview` that deploy to standard compute (e.g., regular ACI or Kubernetes pods). These recipes might ignore or log a warning for confidential container requests if they don't support them. | ||
| * Example recipe registration (conceptual): | ||
| ```bash | ||
| rad recipe register std-container-recipe --environment std-env \ |
There was a problem hiding this comment.
I strongly believe we should not have any recipe names. This leaks the implementation abstraction into the developers' world. If the developer needs a different recipe, that should be a different resource type.
| // This container requests confidential compute | ||
| extensions: [ | ||
| { | ||
| kind: 'confidentialCompute' // Example extension kind |
There was a problem hiding this comment.
If there are additional properties needed to be set by the developer, that should be a different resource type. I do not think extension is the right thing here, nor do I understand how one would create an extension.
| 3. **Developer/CI/CD: Deploy the Same Application Definition to Both Environments** | ||
| * **Deploy to Standard Environment:** | ||
| * `rad deploy ./app.bicep --environment std-env` | ||
| * Radius uses the `std-container-recipe` registered in `std-env`. |
There was a problem hiding this comment.
Radius will use the default recipe unless named by the developer. But specifying the recipe name is only supported by portable resource types today.
There was a problem hiding this comment.
this was a mistake, corrected them all to be registered as default
|
|
||
| 1. **Define a Recipe Pack**: | ||
| * A platform engineer creates a manifest file (e.g., `recipe-pack.json` or `recipe-pack.yaml`) that defines a collection of recipes. This manifest would list each core resource type (e.g., `Applications.Core/containers@2025-05-01-preview`, `Applications.Core/gateways@2025-05-01-preview`, `Applications.Core/secretStores@2025-05-01-preview`) and associate it with a specific recipe (OCI URI or local path) and its default parameters. | ||
| * Example `recipe-pack.yaml`: |
There was a problem hiding this comment.
Is there anything here that isn't just an Environment? Sort of seems redundant.
There was a problem hiding this comment.
@brooke-hamilton asked a similar question, see answer in a previous comment: https://github.com/radius-project/design-notes/pull/96/files#r2141274374
There was a problem hiding this comment.
This question has come up a few times. I've added it to the "Questions to answer" section of this spec.
| 1. **Configure Environment-Specific Recipe Parameters (Optional)**: | ||
| * If recipes have parameters that need to be set globally for an environment, configure them using `rad recipe update` or during registration. | ||
|
|
||
| #### Packaging and Registering a "Recipe Pack" for an Environment: |
There was a problem hiding this comment.
A "resource pack" would be more useful. It would be a manifest of resource types and associated recipes. I would specify the resource pack during rad init.
There was a problem hiding this comment.
Could we define a set of resources and a set of recipes within a single environment resource, and deploy that? That could replace the need for recipe or resource packs.
There was a problem hiding this comment.
@brooke-hamilton see answer in a previous comment: https://github.com/radius-project/design-notes/pull/96/files#r2141274374
@zachcasper - I'm thinking Recipes and Resources would be bundled into the same pack - it seems pointless to have them separately as one wouldn't be used without the other. Thoughts?
| ``` | ||
| 1. **Package the Recipe Pack (Optional but Recommended)**: | ||
| * The manifest file and any local recipe files (if not using OCI URIs exclusively) could be bundled into an OCI artifact or a simple archive (e.g., .zip, .tar.gz) for easier distribution and versioning. | ||
| 1. **Register the Recipe Pack to an Environment**: |
There was a problem hiding this comment.
Register isn't the right verb here. We're configuring the environment. rad environment create --recipe-pack <location> seems more accurate.
There was a problem hiding this comment.
Good point, I've changed it to leverage the rad environment update my-env --recipe-pack ... command instead.
| 6. **Update CI/CD Pipelines**: | ||
| * Modify CI/CD pipelines to use the updated application Bicep files and any new CLI commands or Radius versions required for the UDT model. | ||
|
|
||
| ## Key investments |
There was a problem hiding this comment.
Do we want to mention user experience when there are errors either at registering or deployment. We could deploy partial resources and users will need to be aware.
There was a problem hiding this comment.
Yes, I've added error scenario details to the user scenarios section.
| source: cache.id | ||
| } | ||
| } | ||
| extensions: [ |
There was a problem hiding this comment.
I think the need for extensions, aka "punch through", goes away with RRTs and recipes. If a platform engineering team needs platform-specific configuration they would implement it in the recipe and maybe provide the developers with configuration options in the RRT.
There was a problem hiding this comment.
While I agree with your perspective on this, I'm inclined to keep the Dapr configurations as-is for now (i.e. within the extensions property) but removing everything else out of extensions. I think the removal of Dapr as a built-in first class integration in Radius is out of scope for this feature spec as that requires a separate set of considerations that is orthogonal to the compute extensibility goals.
If needed, we can discuss further, @brooke-hamilton
| #### Creating and registering custom Recipes for core types: | ||
| 1. **Create and Register Recipes for Core Types**: | ||
| * Create custom Bicep/Terraform recipes for `Applications.Core/containers@2025-05-01-preview`, `Applications.Core/gateways@2025-05-01-preview`, and `Applications.Core/secretStores@2025-05-01-preview` to target a specific platform or customize existing behavior. | ||
| * Publish these recipes to an OCI registry for Bicep or a Terraform module repository. |
There was a problem hiding this comment.
Can we also have a platform engineering scenario in which someone is developing a recipe and iterating through multiple changes to the recipe and RRT? It would be nice to have the ability to register a recipe and RRT that are on the local dev machine, without having to upload to an OCI registry.
Another scenario might be to clone a repo that contains RRTs and recipes, and register them as local files instead of being in an OCI registry.
There was a problem hiding this comment.
Great idea, I added some scenarios for this.
| resource env 'Applications.Core/environments@2025-05-01-preview' = { | ||
| name: 'my-aci-env' | ||
| properties: { | ||
| - compute: { | ||
| - // compute kind is no longer hard-coded here | ||
| - } | ||
| recipes: { | ||
| 'Applications.Core/containers': { | ||
| default: { | ||
| templateKind: 'bicep' | ||
| plainHttp: true | ||
| templatePath: 'ghcr.io/radius-project/recipes/azure/aci-container:latest' | ||
| parameters: { | ||
| defaultCpu: 1 | ||
| defaultMemoryInGB: 2 | ||
| } | ||
| } | ||
| } | ||
| 'Applications.Core/gateways': { | ||
| default: { | ||
| templateKind: 'bicep' | ||
| plainHttp: true | ||
| templatePath: 'ghcr.io/radius-project/recipes/azure/aci-gateway:latest' | ||
| parameters: { | ||
| defaultCpu: 1 | ||
| defaultMemoryInGB: 2 | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
This example nicely demonstrates how recipes can be packaged with an environment. Do we need recipe packs if we have this capability? For example, if I want to deploy to XYZ platform, I can define an environment that contains all the recipes needed to deploy to that platform.
There was a problem hiding this comment.
The convenience of Recipe packs will be needed so that platform engineers don't have to piece together individual Recipes for each environment from scratch. Putting everything together manually each time also opens up the door for error (e.g. forgetting to include gateway Recipes). I think what you're describing might be a good solution for grouping collections of Recipe packs - e.g. I bundle ACI and OpenAI Recipe packs together in an Environment.
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
…com/willtsai/design-notes-radius into compute-extensibility-feature-specs
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
| - Default Recipes can be leveraged for the standard container resource type for platforms that don't require platform-specific configurations. For example, the default Kubernetes Recipe can be used for the standard container resource type without any modifications, while the ACI Recipe can be modified to leverage the platform-specific capabilities. | ||
|
|
||
| **Cons:** | ||
| - Exposing the entire set of container configurations in order to allow for platform specific capabilities may be too broad of an abstraction punch-through, resulting in container infrastructure configurations being split or duplicated across two places (i.e. in the container resource definition itself and in the Recipe). |
There was a problem hiding this comment.
How is a property setting exposing too much to the developers? runtimes should be something they never mess with unless in coordination with the recipe writers. I'd expect it to be optional
There was a problem hiding this comment.
We solicited feedback from a Radius user (platform engineering team) who was against exposing this to developers. Their reasoning was that such a punch-through exposed to developers can lead to misuse and complications as the container contract becomes ambiguous (i.e. they have to manage a separate contract with their developers on what is and isn't allowed in the punch-through). They prefer to keep the core properties limited and manage additional requirements through platform engineering.
| This option is where the advanced capabilities are not exposed in the standard container properties provided by Radius out of the box, but rather require platform engineers to modify the container resource definitions to enable these capabilities. This could be done by creating a custom Radius Resource Type (RRT) that extends the standard container RRT to include platform-specific properties or configurations. | ||
|
|
||
| **Pros:** | ||
| - Keeps the standard container resource type clean and focused on core properties, avoiding clutter from platform-specific configurations or misuse of advanced container configurations by developers. |
There was a problem hiding this comment.
How is this cleaner than a runtimes property not used by developers in 99% of cases?
There was a problem hiding this comment.
I think the common container properties that make up 90% of the developer use cases need to be elevated into the top-level container properties in the core container resource type. Properties such as restartPolicy that aren't part of the top-level container properties today should added into the core container RRT as this is a configuration common across platforms. This would be the mitigation against the strong need for punch-throughs today.
| <!-- What role does Recipe packs play in this feature? What are solutions for bundling together multiple packs of Recipes? --> | ||
| This specification proposes the introduction of "Recipe Packs" to group related Recipes together for easier management and deployment. The convenience of Recipe packs will be needed so that platform engineers don't have to piece together individual Recipes for each environment from scratch, as a single Recipe Pack may be re-used for many Environments. Putting everything together manually each time also opens up the door for error (e.g. forgetting to include gateway Recipes). | ||
|
|
||
| There were several questions about whether Environments, to which platform engineers may register multiple Recipes, essentially serve the same purpose and thus negates the need for Recipe Packs. While this is a valid point, it lacks the flexibility that a dedicated Recipe Pack feature provides where a Recipe Pack can have a lifecycle independent of the Environment and thus may be re-used for many Environments. The Environment definition remains a good place to group collections of Recipe packs - e.g. bundle ACI and OpenAI Recipe packs together in an Environment definition. |
There was a problem hiding this comment.
Community recipe packs could be everything to stand up a new type like Neo4J, etc which contains several recipes for implementation.
| - Platform engineers must modify the container resource definitions to enable advanced capabilities, which may require additional effort and coordination. | ||
| - Limits the ability of developers to leverage advanced container features without involving platform engineers, potentially slowing down the development process. | ||
| - Default Recipes may not be registered for the custom container RRT that is created to leverage platform-specific capabilities, requiring platform engineers to create and register custom Recipes for each platform they want to deploy to. | ||
|
|
There was a problem hiding this comment.
could we publish both to our official definitions?
Radius.Resources/containers
Radius.Resources/extensibleContainers
There was a problem hiding this comment.
Interesting idea, but I'm inclined to take a stance on an approach and let that be the official definition published. I think it'll add extra confusion to include too many options out of the box.
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
Add feature spec for compute extensibility to define requirements and user experience