FEATURE: Kubernetes Probes - Sidecar - Source Generator

[3GDXC]

Consider creating a source generator for creation of a container sidecar that provides kubernetes probe endpoints using HTTP and gRPC protocols and injects the endpoints into the DAPR sidecar if used

[davidfowl]

Can you elaborate? What does that mean? A source generator that would generate what in which project? How would this work locally? How would this be represented in the manifest? How would this work in various environments? Azure container apps, AWS ECS etc.

[3GDXC]

Outline: containers have health checks that have common endpoints for simple startup, readiness, liveness using HTTP and/or GRPC protocols. these endpoints are used for basic monitoring and availability of the microservice.

Idea: provide a simplified way to use healthcheck logic as a HTTP and/or GRPC endpoint status probe without the need for each project to explicitly implement the status probe endpoint within the project source; and remove the need for developers having to think about the deployment of the implementation as a container.

This could be by way of dependency injection and loading into the same process (like Application Insights via ENVIRONMENT setting) and/or sidecar loading of a generated HTTP and/or GRPC service that is executed in its own process and is created based off project annotations.

[davidfowl]

Idea: provide a simplified way to use healthcheck logic as a HTTP and/or GRPC endpoint status probe without the need for each project to explicitly implement the status probe endpoint within the project source; and remove the need for developers having to think about the deployment of the implementation as a container.

The aspire service defaults come with an http-based health checks endpoint (there's no grpc, but we could consider adding it). Why it need to be a source generator (that would be harder to customize).

As for health probes, there are 2 existing issues with more details:

• https://github.com/dotnet/aspire/issues/890
• https://github.com/dotnet/aspire/issues/889

As for this idea, I'd encourage you to build it and flesh out some of the detail a bit more. Also take a look at those issues for overlap. One other thing we haven't solved yet is the security of the health check endpoint. Exposing endpoints that have default logic is always tricky to get right (this is something we want to solve).

[3GDXC]

Idea: provide a simplified way to use healthcheck logic as a HTTP and/or GRPC endpoint status probe without the need for each project to explicitly implement the status probe endpoint within the project source; and remove the need for developers having to think about the deployment of the implementation as a container.

The aspire service defaults come with an http-based health checks endpoint (there's no grpc, but we could consider adding it). Why it need to be a source generator (that would be harder to customize).

As for health probes, there are 2 existing issues with more details:

• Support modeling health probes into the AppHost model for use in dashboard, deployment manifest, etc. #890
• Add health check status to the dashboard #889

As for this idea, I'd encourage you to build it and flesh out some of the detail a bit more. Also take a look at those issues for overlap. One other thing we haven't solved yet is the security of the health check endpoint. Exposing endpoints that have default logic is always tricky to get right (this is something we want to solve).

in general the though around source generator was to use annotations and metadata attribution of classes/methods could be used to allow developers to indicate what code is to be executed with in a artifact/assembly (like the HostingStartup attribute) for the probe health check without the need for reflection (speed and support for AOT compilation) something like

[ApplicationProbeCheck(ProbeType = ProbeType.Startup]
public HealthStatus ServiceProbeStartup([IServiceProvider]) ...

[ApplicationProbeCheck(ProbeType = new { ProbeType.Startup, ProbeType.Readiness,   ProbeType.Liviness }]
public HealthStatus ServiceProbe([IServiceProvider]) ...

security for the probe may use the same attributes present in ASPNETCORE and/or be extended with features that use shared public keys and generate TOTP for external access which depending on requirements of deployments.

the resulting probe endpoint/service would also be rate limited to prevent DOS attacks etc.

[davidfowl]

This doesn't really seem related to aspire per se, seems more like an asp.net core health checks feature. One of the aspire principles is to build things into the right layer of the stack. This feel like it would be useful in a regular asp.net core eapplication.