Throw a friendly error from Aspire if Docker isn't running

[JamesNK]

This is what a user sees today if they run Aspire and docker isn't running.

Should display a nice, friendly error message. Something like, "Failed to connect to Docker. Ensure that Docker is running."

[JamesNK]

Is there a different error if Docker isn't installed? Should test that scenario and ensure there is a good error message.

[maddymontaquila]

For the lurkers, this is a huge lift to actually fix, so in the meantime we definitely need to make the error message palatable and actually informative. There is a diff error if docker isnt installed.

Another option is to still launch the dashboard instead of throwing, and we show a banner or popup that suggests starting docker.

[maddymontaquila]

cc @leslierichardson95

[davidfowl]

Another idea would be to lean into the dashboard and show it there instead of stopping the application from starting. Container resources would fail and we with the new restart feature, maybe enable restarting the container.

This would only happen if the dashboard was enabled. Else, it would continue to throw.

[JamesNK]

There isn't an API for the host to tell the dashboard to show messages. But since we know if docker is healthy or not before the dashboard is started, the dashboard could have some extra configuration options to display a message on startup. Hosting sets those when it starts the dashboard.

The startup message can use the existing message UI. Today it's used to display a message that telemetry isn't secured, or max telemetry reached. But it can show multiple messages at once.

[maddymontaquila]

My proposal for this as a SUPER short term thing for 9 -

instead of "fail" in the terminal, we show "warn": Microsoft.Extensions. Hosting failed to start. Please check that your container runtime is started.

And instead of not launching the dashboard, we still launch but anything that relies on a container runtime is listed as "Failed to Start" in the dashboard resource view.

9.1+ we could prob do some tooltips in the dashboard, etc

Thoughts??? @davidfowl @mitchdenny @DamianEdwards @JamesNK

[DamianEdwards]

Quick hack-up just now on my machine, this is what it looks like after starting TestShop without Docker running:

[DamianEdwards]

OK a bit more chatting with @davidfowl @karolz-ms and @danegsta just now, here's the proposed click-stops to improve this UX:

1. Aspire.Hosting is updated so that when the dashboard is enabled, the app host is not stopped when a container runtime issue is detected (i.e. the image above). This means if Docker is not running, the dashboard will start but all container-based resources (or resources that are configured to wait for container-based resources) will fail to start. The app host console log and the individual resource console logs will contain the container runtime error message. The container resources will not have the lifecycle commands added so they can't be started from the dashboard.

   We should commit to this for 9.0. Branch with these changes is here.

2. DCP is updated (along with any required Aspire.Hosting changes) so that container-based resources can be started from the dashboard after they initially failed to start due to a container runtime issue. Right now this is blocked as DCP doesn't recover if the container runtime wasn't healthy when DCP was started but then becomes healthy later. This means the following flow will succeed:

   1. Start the app host when container runtime is stopped
   2. Dashboard appears and shows all container resources in "Failed to start" state
   3. Container runtime is started by the user
   4. Container resources can be started from the dashboard now that the container runtime is running.

• We will attempt to do this for 9.0, but it might slip to 9.1 depending on how the changes in DCP go.*

3. DCP and Aspire.Hosting are updated so that container-based resources will automatically be started once the container runtime becomes healthy if they initially failed to start due to the container runtime being unhealthy at DCP launch. This means the following flow will succeed:

   1. Start the app host when container runtime is stopped
   2. Dashboard appears and shows all container resources in "Failed to start" state
   3. Container runtime is started by the user
   4. Container resources will automatically start

   This is the "north star" goal for post-9.0

[JamesNK]

As well as the error message from connecting to Docker, I'd like the logs to display an extra message that we add. Something as simple as "Failed to connect to Docker. Ensure that Docker is running." would make it clear what is wrong and what they need to do.

[JamesNK]

By the way there was a bug that causes these resource logs to be lost. A fix was just checked in to preserve them.

[davidfowl]

As well as the error message from connecting to Docker, I'd like the logs to display an extra message that we add. Something as simple as "Failed to connect to Docker. Ensure that Docker is running." would make it clear what is wrong and what they need to do.

We need to handle multiple container runtimes.

[DamianEdwards]

I updated the existing message so that it includes a suggestion to check that the container runtime is running and try again.

[davidfowl]

PR up https://github.com/dotnet/aspire/pull/6135