Multiple bicep extensions that share an implementation

[rynowak]

Is your feature request related to a problem? Please describe.

As part of Radius we're adding user-defined types resource types. This has an overlapping name with the UDT feature of Bicep, but it's different 😆.

This will allow a user to:

• Define their own resource types using a simplified YAML format
• Upload that data to Radius so our API can process it
• Generate a Bicep extension for local tooling support

This is a lot like Kubernetes CRDs but inside Radius.

---

The challenge is that there is no "server side" extension in the deployment engine. We need to instead treat these extensions as part of Radius, and let them get processed by the Radius extension in the deployment engine.

Essentially, users are bringing their own type definitions that augment our extension, and can be processed by our extension.

This is extensible, so we can't hardcode names.

---

As a thought experiment, the Kubernetes extension in Bicep has the same challenge. It only knows about resource types that are in the box, yet Kubernetes is extensible. Any user that wanted to ship a library of Kubernetes types would end up with the same requirements.

Describe the solution you'd like

I think the ideal thing would be an "alias" feature. A way for a client-side extension to instruct the server which extension id should be responsible for processing.

Any solution would be acceptable as long as it...

• Is extensible by users (no hardcoded names)
• Doesn't require users to implement server-side Bicep extensions

We have control over our deployment engine code as well, but we'd like to rely on extensibility where possible.

[alex-frankel]

@rynowak - FYI putting this into our backlog. It likely won't move until your priority changes/you run into roadblocks with your plan.