Skip to content
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.

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

Model Dapr sidecar as an Aspire resource #1604

Merged
merged 7 commits into from
Jan 10, 2024

Conversation

philliphoff
Copy link
Contributor

@philliphoff philliphoff commented Jan 9, 2024

Currently, Dapr sidecars are modeled as annotations on a parent resource, which indicates the need for a Dapr sidecar started for that resource. The Dapr lifecycle hook will then generate appropriate Dapr CLI executable resources to start the sidecars. When publishing, that hook will write Dapr sidecar resources to the manifest.

This model has a disadvantage in that, because the sidecars are not true resources, users cannot modify them like other resources (e.g. set environment variables). This was done originally due to the tight 1:1 mapping between Dapr sidecar and parent resource. For example, it would be semantically invalid to create a Dapr sidecar resource and then reference it from several resources.

This PR updates the model such that the Dapr sidecar is a true resource, but one exposed only through the existing AddDaprSidecar() API to avoid semantic errors; users cannot create an arbitrary Dapr sidecar resource, only configure the one associated with a given resource. The API allows the existing sidecar options (if any) to be specified, as well as use the existing resource annotation helpers, such as WithEnvironment().

The API looks like:

builder.AddProject<Projects.DaprServiceA>("servicea")
       .WithDaprSidecar(
                 sidecarBuilder =>
                 {
                     sidecarBuilder
                         .WithOptions(new DaprSidecarOptions { ... })
                         .WithEnvironment("DAPR_TEST_VAR", "Dapr Test Value");
                 }
       )

NOTE: Currently only the environment variables annotations are applied to the implicit Dapr CLI executable resource.

Resolves #1553

Microsoft Reviewers: Open in CodeFlow

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication label Jan 9, 2024
@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Jan 9, 2024
@davidfowl
Copy link
Member

We'll end up having 3 resources in the UI once we do this #436

Signed-off-by: Phillip Hoff <[email protected]>
@philliphoff
Copy link
Contributor Author

We'll end up having 3 resources in the UI once we do this #436

I'm ok with that, though I'm curious as to what the UX for that will be like. It'd be neat to be able to arrange the resources in some sort of hierarchical way.

@davidfowl davidfowl merged commit 859a603 into dotnet:main Jan 10, 2024
8 checks passed
@GFlisch
Copy link

GFlisch commented Jan 10, 2024

Any idea when the preview3 with this feature will be available?

@davidfowl
Copy link
Member

February is the next release. You can use ci builds to help verify this feature though.

@philliphoff philliphoff deleted the philliphoff-dapr-environment branch January 10, 2024 07:37
@bit365
Copy link

bit365 commented Jan 19, 2024

thanks ^_^

@github-actions github-actions bot locked and limited conversation to collaborators Apr 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-app-model Issues pertaining to the APIs in Aspire.Hosting, e.g. DistributedApplication community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Using WithEnvironment after dapr doesn't work
4 participants