Skip to content

Feature spec: compute extensibility user experience #96

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
willtsai merged 89 commits into from
Aug 29, 2025
Merged

Feature spec: compute extensibility user experience #96

willtsai merged 89 commits into from
Aug 29, 2025

Conversation

@willtsai
Copy link
Contributor

@willtsai willtsai commented Jun 4, 2025

Add feature spec for compute extensibility to define requirements and user experience

@willtsai
Feature spec: compute extensibility user experience
33152c1 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai willtsai requested review from a team as code owners June 4, 2025 05:27
willtsai added 3 commits June 3, 2025 22:28
@willtsai
Gemini 2.5 Pro authored this initial commit
96399df 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
first edits
be2782a 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
update detailed user steps
502222b 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai willtsai marked this pull request as draft June 6, 2025 18:17
willtsai added 2 commits June 6, 2025 17:01
@willtsai
add details for user experience steps and feature investments (Gemini…
378ada8 
… 2.5 Pro assisted in VSCode)

Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
add terms, conf containers, spelling
8b611d2 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai willtsai marked this pull request as ready for review June 10, 2025 18:09
sylvainsf
sylvainsf reviewed Jun 10, 2025
View reviewed changes
jonvsm
jonvsm reviewed Jun 10, 2025
View reviewed changes
sylvainsf
sylvainsf reviewed Jun 10, 2025
View reviewed changes
sylvainsf
sylvainsf reviewed Jun 10, 2025
View reviewed changes
sylvainsf
sylvainsf reviewed Jun 10, 2025
View reviewed changes
sylvainsf
sylvainsf reviewed Jun 10, 2025
View reviewed changes
sylvainsf
sylvainsf reviewed Jun 10, 2025
View reviewed changes
sylvainsf
sylvainsf reviewed Jun 10, 2025
View reviewed changes
@willtsai
edit examples, spelling
a58cc1a 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
ytimocin
ytimocin reviewed Jun 10, 2025
View reviewed changes
nithyatsu
nithyatsu reviewed Jun 10, 2025
View reviewed changes
@willtsai
spelling
c623e46 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
lakshmimsft
lakshmimsft reviewed Jun 10, 2025
View reviewed changes
sk593
sk593 reviewed Jun 10, 2025
View reviewed changes
@willtsai
formatting
d658c0b 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
nicolejms
nicolejms reviewed Jun 10, 2025
View reviewed changes
iyyappam
iyyappam reviewed Jun 10, 2025
View reviewed changes
nicolejms
nicolejms reviewed Jun 10, 2025
View reviewed changes
zachcasper
zachcasper reviewed Jun 10, 2025
View reviewed changes
lakshmimsft
lakshmimsft reviewed Jun 10, 2025
View reviewed changes
@willtsai
update duplicate recipe detection details and container-secrets inter…
293774a 
…actions

Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
address feedback
1e8d251 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
Copy link
Contributor Author

willtsai commented Aug 14, 2025

Should Radius.Core/environments and Radius.Core/applications actually be Radius.Config/environments and Radius.Config/applications to align with Radius.Config/recipePacks? And then have a requirement that everything in the Radius.Config/* namespace are not resource types that can be provisioned by Recipes, etc.

@willtsai
address feedback
ab485f2 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
Merge branch 'main' into compute-extensibility-feature-specs
f41759f 
Signed-off-by: Will <28876888+willtsai@users.noreply.github.com>
@willtsai
spelling
b80db77 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
add reference to config spec
a362088 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
add reference to config spec
7502069 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@zachcasper
Copy link
Contributor

zachcasper commented Aug 19, 2025

Should Radius.Core/environments and Radius.Core/applications actually be Radius.Config/environments and Radius.Config/applications to align with Radius.Config/recipePacks? And then have a requirement that everything in the Radius.Config/* namespace are not resource types that can be provisioned by Recipes, etc.

Interesting thought. I don't have strong opinions here. I lean towards keeping the set of namespaces as simple as possible—I see few benefits for breaking things down into separate namespaces. Thoughts on how to decide:

  • Start with the number of namespaces at an absolute minimum --> Say let's start with one
  • We should have a separate namespace for application resources (containers, secrets, volumes, databases, etc.) and for system resources (environments, recipe packs, terraform settings, etc.) --> So we now have two (Radius.Config and Radius.Compute)
  • We should consider how RBAC would work. Platform engineers would setup role definitions with actions (CRUDL) and scope (resource type namespaces) --> RBAC scope could be a namespace or a resource type, so this has no impact
  • Add any practicalities to make the system easier to understand --> We already agreed on Radius.Data and Radius.Security

So, I would say we would have:

  • Radius.Config/environments
  • Radius.Config/recipePacks
  • Radius.Config/terraformSettings (coming soon)
  • Radius.Compute/applications (for simplicity)
  • Radius.Compute/containers
  • ...

@willtsai
Copy link
Contributor Author

willtsai commented Aug 19, 2025

Should Radius.Core/environments and Radius.Core/applications actually be Radius.Config/environments and Radius.Config/applications to align with Radius.Config/recipePacks? And then have a requirement that everything in the Radius.Config/* namespace are not resource types that can be provisioned by Recipes, etc.

Interesting thought. I don't have strong opinions here. I lean towards keeping the set of namespaces as simple as possible—I see few benefits for breaking things down into separate namespaces. Thoughts on how to decide:

  • Start with the number of namespaces at an absolute minimum --> Say let's start with one
  • We should have a separate namespace for application resources (containers, secrets, volumes, databases, etc.) and for system resources (environments, recipe packs, terraform settings, etc.) --> So we now have two (Radius.Config and Radius.Compute)
  • We should consider how RBAC would work. Platform engineers would setup role definitions with actions (CRUDL) and scope (resource type namespaces) --> RBAC scope could be a namespace or a resource type, so this has no impact
  • Add any practicalities to make the system easier to understand --> We already agreed on Radius.Data and Radius.Security

So, I would say we would have:

  • Radius.Config/environments
  • Radius.Config/recipePacks
  • Radius.Config/terraformSettings (coming soon)
  • Radius.Compute/applications (for simplicity)
  • Radius.Compute/containers
  • ...

After discussion, we ended up with this. Everything that is a Radius construct gets named into Radius.Core/*

  • Radius.Core/environments (Radius construct)
  • Radius.Core/recipePacks (Radius construct)
  • Radius.Core/applications (Radius construct)
  • Radius.Config/terraformSettings (coming soon)
  • Radius.Compute/containers
  • ...

@willtsai
address feedback - named recipes and recipePack namespace
a0fb7d3 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
sk593
sk593 reviewed Aug 20, 2025
View reviewed changes
nithyatsu
nithyatsu reviewed Aug 27, 2025
View reviewed changes
architecture/2025-06-compute-extensibility-feature-spec.md

#### Data model approach (PREFERRED)
Recipe packs are modeled as Radius resources, which means they are objects that get saved into the Radius datastore and thus would show up in the app graph data, etc. This approach establishes a new pattern that treats Recipe packs as core Radius resource objects while the Recipes encapsulated in the packs themselves are not. This also means that Recipe packs would be deployed at the Radius resource group level and referenced in each environment within the resource group vs. being deployed within each environment.

Copy link
Contributor

@nithyatsu nithyatsu Aug 27, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also helps reduce bloat on the environment resource. We have many other properties that environment supports as well, and it is a good idea to refactor some of the information out so that we dont eventually have to create large environment objects close to serialization limits.

brooke-hamilton
brooke-hamilton reviewed Aug 28, 2025
View reviewed changes
architecture/2025-06-compute-extensibility-feature-spec.md Outdated

### Feature 1: RRT Implementation of Core Application Model Types
<!-- One or two sentence summary -->
Re-implement existing core types (`Applications.Core/environments`, `Applications.Core/applications`, `Applications.Core/containers`, `Applications.Core/gateways`, `Applications.Core/secrets`, `Applications.Core/volumes`) as Radius Resource Types (RRT) with new, versioned resource type names (i.e. `Radius.Core/environments`, `Radius.Core/applications`, `Radius.Compute/containers`, `Radius.Compute/gateways`, `Radius.Security/secrets`, `Radius.Storage/volumes`). These RRTs will form the basis of the extensible application model. These new core types must support Connections and may be modified by platform engineers to allow for the configuration of platform-specific capabilities (e.g. confidential containers) in the resource types themselves.
Copy link
Member

@brooke-hamilton brooke-hamilton Aug 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we implement Applications.Core/environments and Applications.Core/applications as RRTs, would customers be able to modify them and create recipes for them? How would we handle this in the CLI and API? Environments and Applications are primary concepts in the CLI, graph, and dashboard, and have expectations about behavior and validation. What would happen if someone registered a new version of those types?

I think there could be value in allowing customers to add on or extend the Environment and Application to track data that is important to them, but that seems out of scope for this feature spec. What do you think?

Copy link
Contributor Author

@willtsai willtsai Aug 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apologies, I will update this. We don't want to implement env and app resources as RRTs for now as these are Radius-specific constructs that don't make sense to be extensible (for now at least).

Copy link
Contributor Author

@willtsai willtsai Aug 29, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated, please take another look @brooke-hamilton

lakshmimsft
lakshmimsft previously approved these changes Aug 28, 2025
View reviewed changes
@zachcasper
Copy link
Contributor

zachcasper commented Aug 29, 2025

Can you move this feature spec into the features directory?

@willtsai
clarify that env and app will not be rrt, clarify ephemeral volumes w…
939e8a7 
…ill be managed by container recipe

Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
clarify that env and app will not be rrt, clarify ephemeral volumes w…
d1cf412 
…ill be managed by container recipe

Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
relocate to /features directory
f9c98ba 
Signed-off-by: Will Tsai <28876888+willtsai@users.noreply.github.com>
@willtsai
Copy link
Contributor Author

willtsai commented Aug 29, 2025 •
edited
Loading

Can you move this feature spec into the features directory?

@zachcasper Done.

brooke-hamilton
brooke-hamilton approved these changes Aug 29, 2025
View reviewed changes
Copy link
Member

@brooke-hamilton brooke-hamilton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚢 🚀 🎉

@willtsai willtsai merged commit 886498d into radius-project:main Aug 29, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@willdavsmith willdavsmith willdavsmith left review comments

@ytimocin ytimocin ytimocin left review comments

@sylvainsf sylvainsf sylvainsf left review comments

@nicolejms nicolejms nicolejms left review comments

@sk593 sk593 sk593 approved these changes

@brooke-hamilton brooke-hamilton brooke-hamilton approved these changes

@lakshmimsft lakshmimsft lakshmimsft left review comments

+6 more reviewers

@jonvsm jonvsm jonvsm left review comments

@iyyappam iyyappam iyyappam left review comments

@YohanSciubukgian YohanSciubukgian YohanSciubukgian left review comments

@zachcasper zachcasper zachcasper approved these changes

@Reshrahim Reshrahim Reshrahim left review comments

@nithyatsu nithyatsu nithyatsu left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.