End-to-end UDT feature spec #81

zachcasper · 2025-02-10T22:28:43Z

User-defined resource type feature request

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

architecture/2025-02-user-defined-resource-type-feature-spec.md

brooke-hamilton

🚀

architecture/2025-02-user-defined-resource-type-feature-spec.md

ytimocin · 2025-02-11T19:28:48Z

architecture/2025-02-user-defined-resource-type-feature-spec/image-20250130153426974.png

nit: typo: ingress

ytimocin · 2025-02-11T19:29:13Z

architecture/2025-02-user-defined-resource-type-feature-spec/image-20250205155136117.png

architecture/2025-02-user-defined-resource-type-feature-spec.md

willtsai · 2025-05-07T18:32:53Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+**`webservice-resource-type.bicep`**:
+
+`````yaml


is this illustrating that composite types can be defined using YAML? would we recommend users against this and point them to defining composite types via Bicep/Terraform Recipes?

It is illustrating that the composite resource type has an interface, this YAML, and an implementation—either in Terraform or Bicep.

architecture/2025-02-user-defined-resource-type-feature-spec.md

lakshmimsft · 2025-05-07T18:34:52Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+                const: true
+          then:
+            required: hostname
+```


Concern on this. if/then is not recognised by OpenAPI3.0 spec. Something similar may be achieved perhaps with:

# … required: - environment - container anyOf: - properties: ingress: const: false # when ingress is false, no extra requirement - properties: ingress: const: true required: - hostname

We authored schema design based on openapi 3.0 which brings in structural schema. 3.1 is not widely adopted in field.

Understood. The if/then/else construct is much easier for users than the oneOf/anyOf/allOf. We can discuss in the technical design. If it's not feasible to do if/then/else than anyOf is acceptable.

kachawla · 2025-05-07T18:35:50Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+**Rename of template-kind and template-path** – Radius is not opinionated about which infrastructure as code solution to use. Therefore, it is important that Radius is not biased towards one solution versus another. The parameter `--template-kind` and `--template-path` are biased towards Bicep as Bicep files are called templates and Terraform files are configurations. 
+
+Given this, the `--template-kind` and `--template-path` arguments will be renamed `--recipe-kind` and `--recipe-path`. The previous commands will be retained for backwards compatibility.


The previous commands will be retained for backwards compatibility.

Do we eventually plan to deprecate older version of this command?

architecture/2025-02-user-defined-resource-type-feature-spec.md

kachawla · 2025-05-07T18:38:42Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+    connection: {
+      jira:
+        source: jira.id
+    }


What functionality does this block enable for users when it's defined?

willtsai · 2025-05-07T18:39:26Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+**Retirement of named recipes** – Today, Radius supports named recipes. When deploying a portable resource type, developers can override the default recipe by specifying a recipe name in their application definition. This enables developers to punch through the separation of concerns between platform and developers. Based on strong user feedback, user-defined resource types will not implement the ability to punch through and use alternate recipes. 
+
+Furthermore, once portable resource types are refactored into user-defined resource types, the ability to specify a recipe name will be retired. The command will change from ``rad recipe register <recipeName>` to `rad recipe register`. This also has the benefit of not having to build developer documentation for discovering available recipes. 


I worry that taking away the ability to punch through will cause issues for users down the line who want to use this functionality in ways we don't fully understand yet

nithyatsu · 2025-05-08T23:08:09Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+> [!CAUTION]
+>
+> Today, Radius enforces the ARM API versioning standard. From the [source code](https://github.com/radius-project/radius/blob/main/pkg/cli/manifest/validation.go#L33) `An API version must be a date in YYYY-MM-DD format, and may optionally have the suffix '-preview'. Example: 2025-01-01"`. However, Kubernetes and most cloud-native project follow a [different versioning scheme](https://kubernetes.io/docs/reference/using-api/). The [Terraform versioning scheme](https://developer.hashicorp.com/terraform/plugin/best-practices/versioning) is similar to Kubernetes. Because Radius is cloud provider-agnostic, Radius will not enforce a specific API versioning scheme on the user.
+>


It would be good to confirm this. Since UCP has a long term vision of replacing ARM, we might still want radius resource versioning to be compliant with ARM.

nithyatsu · 2025-05-09T16:28:34Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+  name: 'jira'
+}
+
+// webservice resource, not core container


If webservices deploys multiple containers front-end, reverse-proxy and security scanner,
how would we know which container to set the environement variable on?

This is why my webservice recipe manually sets the environment variables.

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

nithyatsu · 2025-05-09T19:46:28Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+            application:
+              type: string
+              description: "Optional: The application which the resource is associated with"
+            connectionString:


connectionString is outputs of recipe (here without a recipe, something thats accessible?), and marked readonly, correct?

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

nithyatsu · 2025-06-04T18:10:03Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+| ------------------------------------------------------ | ------------------------------------------ |
+| `CONNECTIONS_ORDERSDB_PROPERTIES_ENVIRONMENT`          | `ordersDB.properties.environment`          |
+| `CONNECTIONS_ORDERSDB_PROPERTIES_APPLICATION`          | `ordersDB.properties.application`          |
+| `CONNECTIONS_ORDERSDB_PROPERTIES_DATABASE`             | `ordersDB.properties.database`             |


we decided to leave out env id and app id right?

today for portable resources what we inject is CONNECTIONS_ORDERSDB_DATABASE, there is no "PROPERTIES" - Did we want it different for UDTs?

Based on yesterday's discussion, confirming CONNECTION_ORDERSDB_DATABASE for env names and context.resource.connections.ordersDB.database for recipe context. We are leaving out "properties" since it is redundant.

brooke-hamilton

🚀

brooke-hamilton · 2025-06-04T18:11:08Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+**Summary**
+
+All resource in Radius will support connections to other resources, no matter the type. When a connection exists from a connecting resource (destination) to another connected resource (source), the source resource's properties will be available within the destination resource. In the case of `Applications.Core/containers` these properties are manifested as environment variables.


Nit

Suggested change

All resource in Radius will support connections to other resources, no matter the type. When a connection exists from a connecting resource (destination) to another connected resource (source), the source resource's properties will be available within the destination resource. In the case of `Applications.Core/containers` these properties are manifested as environment variables.

All resources in Radius will support connections to other resources, no matter the type. When a connection exists from a connecting resource (destination) to another connected resource (source), the source resource's properties will be available within the destination resource. In the case of `Applications.Core/containers` these properties are manifested as environment variables.

brooke-hamilton · 2025-06-04T18:13:41Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+The following environment variables are automatically created in the container:
+
+| Environment Variable Name                              | Property Name                              |


How will nested properties be displayed, especially arrays, like ordersDB.properties.fruit.[0] = 'orange'

CONNECTIONS_ORDERSDB_PROPERTIES_CREDENTIALS_USERNAME is an example.

For arrays, I believe in OpenAPI every item has a name correct?

kachawla · 2025-06-04T18:11:13Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+When a developer adds a connection to a `Applications.Core/containers` resource, environment variables for each of the source resource's properties are created within the environment. 
+
+For example, the developer creates a connection to the PostgreSQL resource type from User Story 1. 


from User Story 1

Might be helpful to just paste the whole type here again to make it easier to follow/read.

kachawla · 2025-06-04T18:13:50Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+If the developer prefers for these environment variables to not be created, he/she can set the existing `disableDefaultEnvVars` boolean property to TRUE.
+
+### User Story 9 – Connections into recipes


Would help if you could extend the example to include a real scenario of how a user would use it, and an example of the webservice UDT definition.

kachawla · 2025-06-04T18:16:10Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+If the developer prefers for these environment variables to not be created, he/she can set the existing `disableDefaultEnvVars` boolean property to TRUE.
+
+### User Story 9 – Connections into recipes


Do we have a third scenario for UDT to UDT connections, or does this cover that?

willdavsmith · 2025-06-04T18:17:16Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+| `CONNECTIONS_ORDERSDB_PROPERTIES_PORT`                 | `ordersDB.properties.port`                 |
+| `CONNECTIONS_ORDERSDB_PROPERTIES_CREDENTIALS_USERNAME` | `ordersDB.properties.credentials.username` |
+| `CONNECTIONS_ORDERSDB_PROPERTIES_CREDENTIALS_PASSWORD` | `ordersDB.properties.credentials.password` |
+


so the list of available env vars are defined in the UDT type spec?

yes, all properties are automatically exported as connection vars

lakshmimsft · 2025-06-04T18:19:16Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+**Summary**
+
+All resource in Radius will support connections to other resources, no matter the type. When a connection exists from a connecting resource (destination) to another connected resource (source), the source resource's properties will be available within the destination resource. In the case of `Applications.Core/containers` these properties are manifested as environment variables.


note: We are creating env variables for all udt properties which are simple types: int, float, string

lakshmimsft · 2025-06-12T02:16:16Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+
+**Summary**
+
+All resource in Radius will support connections to other resources, no matter the type. When a connection exists from a connecting resource (destination) to another connected resource (source), the source resource's properties will be available within the destination resource. In the case of `Applications.Core/containers` these properties are manifested as environment variables.


should this be "destination's resource's properties will be available within the source resource"

nithyatsu · 2025-06-17T16:24:21Z

architecture/2025-02-user-defined-resource-type-feature-spec.md

+* `context.resource.connections.ordersDB.properties.size`
+* `context.resource.connections.ordersDB.properties.host`
+* `context.resource.connections.ordersDB.properties.port`
+* `context.resource.connections.ordersDB.properties.credentials.username`


no properties here for example context.resource.connections.ordersDB.properties.size ---> context.resource.connections.ordersDB.size

Also, we decided to leave out standard properties:
context.resource.connections.ordersDB.properties.environment
context.resource.connections.ordersDB.properties.application

# Description This PR adds support for UDt to UDT connections. It also adds E2E covering: 1. container2udt connection ( just bicep. The changes are in container's rendering, therefore the recipe language does not matter) 2. udt2udt connection with bicep recipes 3. udt2udt connection with terraform recipes Design radius-project/design-notes#81 refer ## Scenario 3 – Connections ## Type of change - This pull request adds or changes features of Radius and has an approved issue (issue link required).  Partially Fixes: #6688 ## Contributor checklist Please verify that the PR meets the following requirements, where applicable:  - An overview of proposed schema changes is included in a linked GitHub issue. - [X] Yes  - [ ] Not applicable  - A design document PR is created in the [design-notes repository](https://github.com/radius-project/design-notes/), if new APIs are being introduced. - [X] Yes  - [ ] Not applicable  - The design document has been reviewed and approved by Radius maintainers/approvers. - [X] Yes  - [ ] Not applicable  - A PR for the [samples repository](https://github.com/radius-project/samples) is created, if existing samples are affected by the changes in this PR. - [X] Yes  - [ ] Not applicable  - A PR for the [documentation repository](https://github.com/radius-project/docs) is created, if the changes in this PR affect the documentation or any user facing updates are made. - [X] Yes  - [ ] Not applicable  - A PR for the [recipes repository](https://github.com/radius-project/recipes) is created, if existing recipes are affected by the changes in this PR. - [ ] Yes  - [X] Not applicable  --------- Signed-off-by: nithyatsu <nithyasu@microsoft.com>

zachcasper added 2 commits February 10, 2025 16:24

Initial draft of end-to-end UDT feature spec

9dc0a03

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

Initial draft of end-to-end UDT feature spec

99657b8

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

zachcasper requested review from a team as code owners February 10, 2025 22:28

Small grammar updates

c274481

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

nithyatsu reviewed Feb 11, 2025

View reviewed changes

superbeeny reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

willdavsmith reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

willdavsmith reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

superbeeny reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Show resolved Hide resolved

superbeeny reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

lakshmimsft reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Show resolved Hide resolved

willdavsmith reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

willtsai reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

willdavsmith reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

ytimocin reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

kachawla reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

ytimocin reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

lakshmimsft reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

brooke-hamilton reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

sk593 reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

lakshmimsft reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

willtsai reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

ytimocin reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

willtsai reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

kachawla reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

kachawla reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

ytimocin reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec/image-20250130153426974.png Outdated

Copy link

Contributor

ytimocin Feb 11, 2025

Choose a reason for hiding this comment

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

nit: typo: ingress

ytimocin reviewed Feb 11, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec/image-20250205155136117.png Outdated

Copy link

Contributor

ytimocin Feb 11, 2025

Choose a reason for hiding this comment

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

very cool

kachawla reviewed Feb 21, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

willtsai reviewed May 7, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

willdavsmith reviewed May 7, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

lakshmimsft reviewed May 7, 2025

View reviewed changes

kachawla reviewed May 7, 2025

View reviewed changes

willtsai reviewed May 7, 2025

View reviewed changes

architecture/2025-02-user-defined-resource-type-feature-spec.md Outdated Show resolved Hide resolved

kachawla reviewed May 7, 2025

View reviewed changes

willtsai reviewed May 7, 2025

View reviewed changes

nithyatsu reviewed May 8, 2025

View reviewed changes

nithyatsu reviewed May 9, 2025

View reviewed changes

zachcasper added 6 commits May 9, 2025 13:26

Significant updates to connections

309412f

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

Spelling

7507001

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

Deleting unused images

0990d20

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

Small fixes

4d0b039

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

Spelling

c884f1b

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

Clarified app graph

e4579f6

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

nithyatsu reviewed May 9, 2025

View reviewed changes

zachcasper added 3 commits May 12, 2025 11:47

Simplified connections use cases

bdbcac9

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

Updated after MarkRuss review

30c2756

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

Merge branch 'main' into main

140451d

Signed-off-by: Zach Casper <zachcasper@microsoft.com>

nithyatsu reviewed Jun 4, 2025

View reviewed changes

brooke-hamilton requested changes Jun 4, 2025

View reviewed changes

kachawla reviewed Jun 4, 2025

View reviewed changes

willdavsmith reviewed Jun 4, 2025

View reviewed changes

lakshmimsft reviewed Jun 4, 2025

View reviewed changes

lakshmimsft reviewed Jun 12, 2025

View reviewed changes

nithyatsu reviewed Jun 17, 2025

View reviewed changes

nithyatsu mentioned this pull request Jun 17, 2025

udt to udt connections radius-project/radius#9794

Merged

12 tasks

nithyatsu mentioned this pull request Jun 27, 2025

E2E tests for udt connections radius-project/radius#9856

Open

12 tasks


		Rename of template-kind and template-path – Radius is not opinionated about which infrastructure as code solution to use. Therefore, it is important that Radius is not biased towards one solution versus another. The parameter `--template-kind` and `--template-path` are biased towards Bicep as Bicep files are called templates and Terraform files are configurations.

		Given this, the `--template-kind` and `--template-path` arguments will be renamed `--recipe-kind` and `--recipe-path`. The previous commands will be retained for backwards compatibility.


		Retirement of named recipes – Today, Radius supports named recipes. When deploying a portable resource type, developers can override the default recipe by specifying a recipe name in their application definition. This enables developers to punch through the separation of concerns between platform and developers. Based on strong user feedback, user-defined resource types will not implement the ability to punch through and use alternate recipes.

		Furthermore, once portable resource types are refactored into user-defined resource types, the ability to specify a recipe name will be retired. The command will change from ``rad recipe register <recipeName>` to `rad recipe register`. This also has the benefit of not having to build developer documentation for discovering available recipes.


		Summary

		All resource in Radius will support connections to other resources, no matter the type. When a connection exists from a connecting resource (destination) to another connected resource (source), the source resource's properties will be available within the destination resource. In the case of `Applications.Core/containers` these properties are manifested as environment variables.

	All resource in Radius will support connections to other resources, no matter the type. When a connection exists from a connecting resource (destination) to another connected resource (source), the source resource's properties will be available within the destination resource. In the case of `Applications.Core/containers` these properties are manifested as environment variables.
	All resources in Radius will support connections to other resources, no matter the type. When a connection exists from a connecting resource (destination) to another connected resource (source), the source resource's properties will be available within the destination resource. In the case of `Applications.Core/containers` these properties are manifested as environment variables.


		The following environment variables are automatically created in the container:

		\| Environment Variable Name \| Property Name \|


		When a developer adds a connection to a `Applications.Core/containers` resource, environment variables for each of the source resource's properties are created within the environment.

		For example, the developer creates a connection to the PostgreSQL resource type from User Story 1.


		If the developer prefers for these environment variables to not be created, he/she can set the existing `disableDefaultEnvVars` boolean property to TRUE.

		### User Story 9 – Connections into recipes


		`webservice-resource-type.bicep`:

		`````yaml

End-to-end UDT feature spec #81

Are you sure you want to change the base?

End-to-end UDT feature spec #81

Uh oh!

Conversation

zachcasper commented Feb 10, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

brooke-hamilton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

lakshmimsft May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kachawla May 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nithyatsu May 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nithyatsu May 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lakshmimsft May 7, 2025 •

edited

Loading

kachawla May 7, 2025 •

edited

Loading

nithyatsu May 8, 2025 •

edited

Loading

nithyatsu May 9, 2025 •

edited

Loading

nithyatsu Jun 17, 2025 •

edited

Loading

lakshmimsft Jun 4, 2025 •

edited

Loading