Mounted volume information isn't respected when generating deployment templates

[aaronpowell]

I'm building an app with a Postgres database which I need to ensure some extensions are installed into Postgres for the app to work.

This is a pretty easy solved problem locally, you just add .WithVolumeMount("./database", "/docker-entrypoint-initdb.d", VolumeMountType.Bind) to the resource builder for Postgres (copied from this sample).

But when I scaffold out the infrastructure with azd infra synth (because I wanted to check it before deployment) I noticed that there was no analogy to the WithVolumeMount that would run my SQL script for me.

I don't think that mounting a volume is the right solution when deploying to Azure (given the transient nature of storage), I was thinking that it might generate something that uses the deploymentScripts feature of Bicep.

[davidfowl]

It's unlikely that we'll ship anything for deploying volumes in aspire v1. @mitchdenny has done some thinking here, but it's not baked enough to make it.

[davidfowl]

Bringing this back into preview 5 and assigning to @DamianEdwards. We want to scope this to container resources and a representation in the manifest that is viable that is enough information to make work in deployment environments like ACA and Kuberenetes.

Not sure how much we will need to scope, but we just need an initial investigation.

Related to #1521

[aaronpowell]

I wonder if there's a way Aspire can try to determine what the objective of the volume mount is to then make that objective available to the metadata and then the IaC generator can generate the appropriate output.

If we use the example in the DatabaseContainers sample the reason for introducing a volume mount is to run a SQL script on startup of the container (to, say, pre-provision the db).

Expanding this objective out to an Azure context, we'd be wanting a PostgreSQL db and we can then use a deploymentScript resource to run the script against the Azure PostgreSQL service that's been deployed.

[davidfowl]

The goal is to represent the existing information in the model since what we have today is lossy. Then we need to figure out if reflecting what we have in the manifest is enough for the container scenario. Mapping deployment scripts that run against the cloud database is magical and out of scope.

However, it would OK if that were an explicit API on top of the existing model being built in preview4 and beyond:

var pg = builder.AddPostgres("pg")
                .WithVolume(...)
                .PublishAsAzurePostgresFlexibleServer(azurePg => 
                {
                       azurePg.RunDeploymentScript(.....);
                })
                .AddDatabase("db");

[DamianEdwards]

Closing this done via #2742 as the scope was constrained to writing out the volume details to the manifest.