search

dotnet / aspire

An opinionated, cloud ready stack for building observable, production ready, distributed applications in .NET
https://learn.microsoft.com/dotnet/aspire
MIT License
3.66k stars 417 forks source link

Replica information not part of deployment manifest #2629

Open timheuer opened 6 months ago

timheuer commented 6 months ago

Given:

var builder = DistributedApplication.CreateBuilder(args);

var apiService = builder.AddProject<Projects.aspirehost80_ApiService>("apiservice")
    .WithReplicas(5);

builder.AddProject<Projects.aspirehost80_Web>("webfrontend")
    .WithReference(apiService);

builder.Build().Run();

When producing a deployment manifest the 5 replicas declared for the apiservice are not a part of the deployment manifest.

Why I expected this... Because now when I deploy to a new ACA environment, I have to now either modify the bicep + deploy, or go to portal and change scaling which triggers anoher revision.

For k8s, I have nothing to translate to my k8s deployment manifest and would have to modify intermediary again.

Kinda just expected that to be a part of my deployment manifest and not needed to be protected from generation.

davidfowl commented 6 months ago

Should we be coupling dev time replica information to deployment time? For ACA is the min or max?

bradygaster commented 6 months ago

I think WithReplicas should impact the number of instances deployed to ACA (or K8S). If I specify WithReplicas(3) I mean, very explicitly and deliberately, that "I want 3 replicas of this project running." If we don't think WithReplicas is the right place to put that-which-is-deployed/published, fine, but, we should give customers a way to control the # of min/max replicas, in local, and deployed, scenarios.

mitchdenny commented 5 months ago

I think we tackle this when we look at owning container app creation from the app model Bicep.