Recipe packs #109
Recipe packs #109
Conversation
Signed-off-by: nithyatsu <nithyasu@microsoft.com>
Signed-off-by: nithyatsu <nithyasu@microsoft.com>
|
|
||
| As an operator I am responsible for creating Radius Environments using which developers can deploy their applications. As part of creating the environment, I manually link recipes one by one using `rad recipe register` or by updating the environment definition. This can be error prone when there are many recipes and environments. Radius should provide a way to bulk register( and manage) recipes. | ||
|
|
||
| #### Registering recipes to multiple environment |
There was a problem hiding this comment.
| #### Registering recipes to multiple environment | |
| #### Registering the same set of recipes to multiple environments |
| Recipe Packs would bundle together Recipes, as we understand them today. We do not cover recipe versioning / other recipe specific enhancements in this design. | ||
|
|
||
|
|
||
| ### User scenarios (optional) |
There was a problem hiding this comment.
One more scenario I suggest adding is the ability to share Recipe Packs across environments or even organizations. e.g. Azure or AWS might create Recipes and bundle them into a Recipe Pack that can be used off the shelf, compute platform specific packs (e.g. Kubernetes, ACI) that ship with Radius by default
| - Helps reduce the size of environment resource, which could reach serization limits with tons of recipes. | ||
| - Helps reduce overall size of Radius datastore, since common recipe information could now be stored as a single resource instead of being duplicated across several environments. | ||
|
|
||
| [Question]: would environment and recipe pack ever have different rbac? |
There was a problem hiding this comment.
I don't think Recipe Packs have RBAC? They should just inherit whatever RBAC is needed to drive its constituent Recipes, which in turn inherits RBAC from the Environment it's registered to?
| Cons: | ||
|
|
||
| - This approach is a deviation from the current tooling approach for recipes. | ||
| - While this brings in many advantages, RRTs can have their schema modified using rad resource-type commands. We should find ways to prevent this from happening. In general, Radius.Core namespace would have resources whose schema should be non-editable so that Radius can work as expected. Some other resources that would fall in this category are environments and applications. |
There was a problem hiding this comment.
This is an interesting take - we'd have to make parts of the Recipe Pack schema non-editable while other parts of it must remain editable (e.g. the set of Recipes bundled into the Pack)
|
|
||
| Today the RRT schema does not allow `any` as a type for security reasons. We would have to remove that constraint in bicep tooling and radius so that we can have the recipe parameters as defined above. | ||
|
|
||
| // Question: The recipe collection should be curly braces, is that OK (feature spec has []) ? OR we keep it array like below. Map could make it easier to look up using resource type. |
There was a problem hiding this comment.
I'm indifferent. If map works better, that's alright!
|
|
||
| ### API design (if applicable) | ||
|
|
||
| We should support CRUDL operations on recipe-pack resource. This should be fairly automatic since recipe packs would be registered as an RRT. Once we register the schema for `Radius.Core/recipePacks` resource type using `rad resource-type create`, Dynamic RP should be able to dynamically look up the schema and perfom these operations. |
There was a problem hiding this comment.
Question to ponder: should Recipe Packs resource not be modeled as an RRT? Since it's a Radius construct and we don't expect users to need to customize their Recipe Packs?
No description provided.