Deployment stuck in "Pending" state when using Aspire.Hosting.Azure.Sql locally

[yorek]

Describe the bug

When using AddAzureSqlServer("").RunAscontainer() using the Aspire.Hosting.Azure.Sql package, the deployment just hangs. No error, no logs...just hanging, and deployment reports "Pending" as a status.

Regression

No response

Steps to reproduce

var sqlSrv = builder.AddAzureSqlServer("sql")
    .RunAsContainer();    

var sqlDb = sqlSrv.AddDatabase("aspiretodo");

var dbPrj = builder.AddSqlProject<Projects.TodoDB>("tododb")    
    .WithReference(sqlDb)    
    .WaitFor(sqlDb);

Expected behavior

Deploy the database project

Screenshots

No response

IDE and version

Other

IDE version

VS Code

Nuget packages

<PackageReference Include="Aspire.Hosting.AppHost" Version="9.1.0" />
<PackageReference Include="Aspire.Hosting.Azure.Sql" Version="9.1.0" />
<PackageReference Include="Aspire.Hosting.NodeJs" Version="9.1.0" />
<PackageReference Include="Aspire.Hosting.SqlServer" Version="9.1.0" />
<PackageReference Include="CommunityToolkit.Aspire.Hosting.Azure.DataApiBuilder" Version="9.2.0" />
<PackageReference Include="CommunityToolkit.Aspire.Hosting.NodeJS.Extensions" Version="9.2.0" />
<PackageReference Include="CommunityToolkit.Aspire.Hosting.SqlDatabaseProjects" Version="9.2.1" />

Additional context

No response

Help us help you

Yes, I'd like to be assigned to work on this item

[aaronpowell]

Related to #434 I believe

[ErikEJ]

@yorek What happens if you remove usage of SQL Projects?

Can you share a dashboard screen shot?

@aaronpowell Yes, sounds related to #434

https://github.com/CommunityToolkit/Aspire/blob/main/src/CommunityToolkit.Aspire.Hosting.SqlDatabaseProjects/SqlProjectBuilderExtensions.cs#L197

[aaronpowell]

That looks like a good catch. I wonder how we can best tackle it, do we create a separate Hosting.SqlDatabaseProjects.Azure integration or roll it into the existing. Rolling with the existing does mean that if you're not using Azure you still end up with Azure in the dependency stack, but a separate integration feels like major overkill

[ErikEJ]

What is the difference between

builder.AddAzureSqlServer("sql")
.RunAsContainer();

And

.AddSqlServer

Is it deployment support or anything else?

[ErikEJ]

if you're not using Azure you still end up with Azure in the dependency stack,

@aaronpowell If you use Microsoft.Data.SqlClient you end up with a lot of Azure "stuff" anyway currently.

[ErikEJ]

It was local deployment: https://github.com/dotnet/aspire/blob/main/src/Aspire.Hosting.Azure.Sql/AzureSqlExtensions.cs#L167

[ErikEJ]

What if the Resource classes here were in a seperate package?

https://github.com/dotnet/aspire/tree/main/src/Aspire.Hosting.Azure.Sql

[aaronpowell]

Thinking through this, the question, in my mind, is "what happens if it's an Azure SQL resource?", as in, not configured to be a container locally, just purely an Azure SQL resource - should (can?) it deploy to Azure SQL?

Since the SqlDatabaseProjects package doesn't produce anything in the manifest, it means we have to be careful on how the support works. Take this code for example:

var sqlSrv = builder.AddAzureSqlServer("sql");    

var sqlDb = sqlSrv.AddDatabase("aspiretodo");

var dbPrj = builder.AddSqlProject<Projects.TodoDB>("tododb")    
    .WithReference(sqlDb)    
    .WaitFor(sqlDb);

What happens when you use Aspire to deploy? Well, the AddSqlProject is ignored from the manifest, but you have the expectation that something should have happened because running locally it did deploy to the Azure resource. There's an obvious argument against using the Azure SQL database for local development, but it's something people can, and may need to, do.

So back to the problem at hand, I think this works (I haven't tested):

var dbPrj = builder.AddSqlProject<Projects.TodoDB>("tododb");

var sqlSrv = builder.AddAzureSqlServer("sql")
    .RunAsContainer(resource => {
      // find databases from the resource, or maybe via the builder
    });    

var sqlDb = sqlSrv.AddDatabase("aspiretodo");

The callback provided to RunAsContainer receives the IResourceBuilder<SqlServerServerResource> which does have the names of all the databases on it, and you can use that to get the IResourcesCollection from the builder and then grab it. It wouldn't be "pretty", but it'd be doable.

[yorek]

Hey both, from my understanding the RunAsContainer creates a local container to simulate Azure SQL db locally. I would expect during the deployment phase that an Azure SQL DB is created instead of having SQL Server deployed in a container in Azure.

[yorek]

"what happens if it's an Azure SQL resource?", as in, not configured to be a container locally, just purely an Azure SQL resource - should (can?) it deploy to Azure SQL?

I think it should, right? Conceptually it would be equivalent to run EF Core migrations against Azure SQL instead of SQL Server and that is expected to work right away

[aaronpowell]

"what happens if it's an Azure SQL resource?", as in, not configured to be a container locally, just purely an Azure SQL resource - should (can?) it deploy to Azure SQL?

I think it should, right? Conceptually it would be equivalent to run EF Core migrations against Azure SQL instead of SQL Server and that is expected to work right away

Yep, I'd expect so (I'm just unfamiliar with the tooling that powers the integration).

Deployment is more complex though, as you need to run the dacpac deployment as part of the Bicep files, which I guess you'd do as a custom script in Bicep, but you'd need to somehow upload the dacpac to somewhere that it can be downloaded in the script run. This is why it's not currently enabled for deployment - deployment makes it complex.

[ErikEJ]

@yorek @aaronpowell

the RunAsContainer creates a local container to simulate Azure SQL db locally.

Yeah, I dug into the source - since there is no "Azure SQL Container" it spins up a plain SQL Server 2022 container...

Deployment is more complex though, as you need to run the dacpac deployment as part of the Bicep files...

Yeah, exactly! And I absolutely agree that this is a noble end goal!

I am not an expert, but maybe the following options are worth investigating:

• The owner of the ARM provider for Azure SQL could potentially add support for continous deployment of a .dacpac, similar to the initial "sampleName" property that is available today. Then that would also become available in Bicep - but as Aaron mentioned, there are probably some challenges around storage/upload of the .dacpac and maybe execution of it (or perhaps that is what "sampleName" already does?
• I understand that 'azd' has an extensibility model, but have not dug further into it.

[yorek]

Yeah, I dug into the source - since there is no "Azure SQL Container" it spins up a plain SQL Server 2022 container...

Yep, that is fine and expected

[ErikEJ]

@yorek We seem to be discussing at least two topics here

• local deployment support
• general production deployment support for SQL Projects

Maybe you should open a new issue for the second topic?

Did you try what @aaronpowell suggested above?

@jmezach Any thoughts on this issue - it would be a great scenario to support.

[jmezach]

@ErikEJ I would definitely want to support the ability to deploy a .dacpac to an Azure SQL-like container during local development. One might argue that at least for local-dev there really isn't a distinction between Azure SQL and SQL Server.

Not sure why it gets stuck into a pending state though. If the target resource is not a SqlServerDatabaseResource, which I'm assuming is the case here, we start deploying as soon as all resources have been created (AfterResourcesCreatedEvent).

[ErikEJ]

@jmezach Good observation. I will attempt to debug..

[yorek]

Ok, let me open a new issue for the .dacpac deployment then. Here we can just continue focusing on the local container. I updated the issue name to better reflect that.

[ErikEJ]

@yorek Thanks, I think you will agree that it takes more than this little NuGet package to accomplish this!

[yorek]

Created: #595

[yorek]

@yorek Thanks, I think you will agree that it takes more than this little NuGet package to accomplish this!

Definitely. I added an idea in the issue I just opened.

[ErikEJ]

@yorek OK, I got some useful insights from @jmezach as usual!

So you should not use .WaitFor() - wonder what made you think it was needed, it is not mentioned in the readme https://www.nuget.org/packages/CommunityToolkit.Aspire.Hosting.SqlDatabaseProjects/9.2.1#readme-body-tab

Removing that will cause deployment to start, but it will fail if you do not have a persisted container and database volume, since it will start too early.

[yorek]

With a regular SqlServer reference (not AzureSqlServer) with WaitFor works perfectly:

var sqlSrv = builder.AddSqlServer("sqlsrv", port:1435)
    .WithLifetime(ContainerLifetime.Persistent);

var db = sqlSrv.AddDatabase("db");

var dbPrj = builder.AddSqlProject<Projects.WeatherDatabase>("dbPrj")
    .WithConfigureDacDeployOptions((options) => options.AllowTableRecreation = false)
    .WithReference(db)
    .WaitFor(db);

So maybe the issues is really not in the SqlDatabaseProject object, but in AzureSqlServer one, and specifically in the RunAsContainermethod?

https://github.com/dotnet/aspire/blob/6fde032d791ac0e0f89daa6f6cbf7724108f458c/src/Aspire.Hosting.Azure.Sql/AzureSqlExtensions.cs#L151

?

[ErikEJ]

@yorek Yes, I think that the RunAsContainer method does not really participate corrrectly in the eventing system

[ErikEJ]

builder.ApplicationBuilder.Eventing.Subscribe<AfterResourcesCreatedEvent>(async (@event, ct) => {
    await RunPublish(builder, target, targetDatabaseName, @event.Services, ct);
});

If the RunAsContainer method was updated for eventing, I think this would work out of the box with the current implementation

[jmezach]

Should we file an issue on the main Aspire repo?

[ErikEJ]

Should we file an issue on the main Aspire repo?

@jmezach I think so, looks like even an attempt was made to fix this: dotnet/aspire#6164

@mitchdenny FYI

[ErikEJ]

@jmezach @yorek I created an issue here: dotnet/aspire#8383

[github-actions]

We have noticed this issue has not been updated within 21 days. If there is no action on this issue in the next 14 days, we will automatically close it. You can use /stale-extend to extend the window.