Specifications for Dapr Binding Implementation

[SoTrx]

Hey,

Here are the proposed specifications for the Dapr Binding implementation.

[lakshmimsft]

Hello @SoTrx. Big thanks for the design doc PR. I've given some initial comments mainly requesting more details in some areas but looking good overall. Thanks a lot!

[rynowak]

Hey @SoTrx - just wanted to drop by and say thanks for doing this. I'll be traveling during the discussion on Monday. I think the template is well filled out 👍 and will lead to the right discussion.

[kachawla]

Thanks @SoTrx, this is a well written doc! Main area that I would like to discuss is the proposal to support manual provisioning instead of recipe based provisioning, pros and cons that led to this decision.

[ytimocin]

Thanks @SoTrx, this is a well written doc! Main area that I would like to discuss is the proposal to support manual provisioning instead of recipe based provisioning, pros and cons that led to this decision.

Just to better understand @SoTrx, we are going to be supporting both types of provisioning by default, right?

[SoTrx]

Thanks @SoTrx, this is a well written doc! Main area that I would like to discuss is the proposal to support manual provisioning instead of recipe based provisioning, pros and cons that led to this decision.

Just to better understand @SoTrx, we are going to be supporting both types of provisioning by default, right?

In my view, recipes aren't necessary for bindings, as they only create the CRD and could lead to a two-step process for creating a single resource.

However, since this indeed contradicts Radius' design policy, how about introducing "common usage binding recipes"?

For instance, we could define an "object-storage binding recipe" that:

• In local development: creates both the binding CRD and the storage backend (e.g., MinIO). (Sample binding)
• In production (Azure): only creates the binding CRD, with a parameter in the recipe to provide the storage account details. (Sample binding)

This approach aligns with Radius' philosophy, is convenient for developers, and retains the core concept of bindings.

[rynowak]

This is a valid usecase (pre-existing resource), but it's not the main one.

We'd usually think about the platform or infrastructure team as being the one to choose the recipes for production usage.

We don't need to impose constraints.

[rynowak]

If the type name is bindings then this should be TrackedResourceRequired<DaprBindingProperties, "bindings">

[willtsai]

In both user scenarios, I recommend elaborating on the user ultimately leveraging Dapr Bindings to accomplish the abstraction, and then they are wanting to make use of these Dapr Bindings in Radius applications. e.g.

As an operator using Radius, I want the application I manage to interface with other applications in my organization without exposing their implementation details to the developers by leveraging Dapr Bindings. Thus, I would like to define and use Dapr Bindings as a resource type within my Radius applications.

[rynowak]

👍 These are a good set of functional tests. 👍 also to avoiding external dependencies for testing where possible.

[rynowak]

I don't quite understand this - apologies, I was out of the office when this was discussed. We have existing recipes for Dapr components that create both the infrastructure and the Dapr Component resource, so I'm not aware of any issues. LMK if I'm missing anything!

[SoTrx]

Sorry for the delay!

There is no issue with the creation process itself. You can create both the Binding CRD and the infrastructure just as you would with any other Dapr Building Block. Users can (and likely will) do this with their own configurations, and we certainly shouldn’t try to restrict that flexibility.

My point is only relevant to the initial binding recipes we plan to provide to users. Here’s some context: the Bindings Building Block is unique in Dapr. It predates most other building blocks and originally served as a way to accomplish tasks that did not yet have dedicated building blocks. This is why some bindings overlap with other blocks, such as Azure Storage Queue.

Bindings are generally basic, often supporting only CRUD-like operations. Additionally, Bindings is the only building block without a unified feature set across multiple backends—nearly every binding is different, and few are interchangeable.

Today, bindings are intended for interacting with external resources, as they are designed for basic interactions. For internal, app-scoped backing services, there is usually a better building block available.

While this approach doesn’t affect how Radius implements Bindings, it does impact the default recipes we include in radius/recipes. If we consider bindings best suited for external resources, then a binding recipe should only contain the Dapr Component CRD. This is why I initially opposed creating binding recipes, as it would involve a two-step process for what is effectively a single CRD creation.

In the first meeting, however, a very good point was raised: from Radius's perspective, it is difficult to justify not having any recipes for a resource.

So, my revised proposal is to create default recipes with this "external resource" perspective in mind. These recipes would set up the backing service in local-dev for convenience, but in production, they would have as input the credentials to an existing backing service. This approach isn’t meant to restrict users but rather as a way to nudge users in the right direction from the start. Of course, users can create custom recipes to override this behavior as they see fit.

I'm not entirely sure if I explained this clearly or if it make sense, so please don’t hesitate to challenge me or ask for clarification on any part of this! And if this direction makes sense, I’m happy to revise the design doc to reflect it.

[rynowak]

So, my revised proposal is to create default recipes with this "external resource" perspective in mind. These recipes would set up the backing service in local-dev for convenience, but in production, they would have as input the credentials to an existing backing service. This approach isn’t meant to restrict users but rather as a way to nudge users in the right direction from the start. Of course, users can create custom recipes to override this behavior as they see fit.

Hey @SoTrx - I appreciate the response 👍

I think the part where I'm stuck is why we need recipes for the "pre-existing" case. This is what resourceProvisioning: 'manual' is for.... when you want to configure the metadata directly.

I'm happy to continue this discussion when we start looking at recipe examples since it's not really going to change the design of the bindings resource type.

[ytimocin]

Other than a few nits, LGTM. Thanks!

[rynowak]

LGTM - thanks for the updates!

[rynowak]

Hi @SoTrx - can you take a look at the spellcheck errors? https://github.com/radius-project/design-notes/actions/runs/11671732590/job/32742154388?pr=68

For any false-positives reported by the spellcheck you can add them here: https://github.com/radius-project/design-notes/blob/main/.github/config/en-custom.txt

Or if they are technical terms I like to use backquotes to turn them into code. like this!

After that I think this is ready to merge.

[SoTrx]

Hi @SoTrx - can you take a look at the spellcheck errors? https://github.com/radius-project/design-notes/actions/runs/11671732590/job/32742154388?pr=68

For any false-positives reported by the spellcheck you can add them here: https://github.com/radius-project/design-notes/blob/main/.github/config/en-custom.txt

Or if they are technical terms I like to use backquotes to turn them into code. like this!

After that I think this is ready to merge.

Hey Ryan,
Sorry, I haven’t been able to work on this lately. Could you rerun the CI? I can’t view the latest spellcheck summary.
Thanks!

[rynowak]

@SoTrx - launched the workflow