Hide Aspire internal/automatic env vars

[JamesNK]

Aspire sets a lot of env vars on a .NET project resource when it starts up. These include, ASP.NET Core env vars for the URL, environment and launch profile. Logging env vars for printing to the console. Service discovery env vars with connection strings and HTTP client addresses. And OTEL env vars to configure .NET OTEL SDK:

Because these env vars are set on the resource by Aspire, they're always visible. I think the vast majority of the time people don't care about these env vars. They create noise and make it harder to find important data in resource details. The exception is probably service discovery env vars.

We should consider hiding internally set env vars so they're only visible when show all is selected.

[JamesNK]

cc @davidfowl @DamianEdwards

[davidfowl]

I don't think we should hide anything. These are what a resource sets, and it's one of the only ways to look at the env at runtime. Developers use these to debug what is being injected into the application.

[JamesNK]

Another problem is sections below the env vars are hidden at the bottom. Health checks for example.

If env vars aren’t changed then they should be last.

[davidfowl]

I don't have a problem with sorting sections but we shouldn't hide any information.

[JamesNK]

I don't have a problem with sorting sections but we shouldn't hide any information.

It's not hidden forever. The user can click on show all to see all env vars set on a resource.

Look at it from a users point of view: they didn't set PATH env var on the resource, so it doesn't show up unless they click "Show all". Makes sense. But they didn't set OTEL_EXPORTER_OTLP_ENDPOINT either, Aspire did that so telemetry is sent to the dashboard, yet OTEL_EXPORTER_OTLP_ENDPOINT is visible in the list of env vars for some reason.

I think we should only show env vars that a user action - such as adding a reference which that populates service discovery env var. The ASP.NET Core env vars for setting app endpoint URLs probably falls into this category.

"System" env vars like OTEL, console logging would be removed from the default view. They could still be viewed by clicking "Show all" icon.

[davidfowl]

I think there's very little value in hiding information from the user. We already hide the system environment variables because it's too much noise, we shouldn't hide environment variables because the user didn't explicit add them and they came from the resource definition. Our users are developers and hiding details is an antipattern. IMO the value of this issue is low.

[JamesNK]

The problem is env vars are still almost all noise. Look at what you see for myfrontend:

50%+ of the data in resource details is env vars that no one cares about.

Compare that with a container that doesn't automatically have a bunch of "system" env vars set on it:

There is no need to spot the important env vars amoungst the OTEL and console log noise, because they're not visible. .NET project resources would be much nicer to view if they showed actually important information like a container does.

0% of people care about what OTEL_BLRP_SCHEDULE_DELAY is. I think I can say that as the person who cares about those env vars most with OTEL + dashboard dev work. Like all these "system" vars, they're always the same value.

This seems like a low effort change to drastically simplify and reduce .NET project resource details view to information people care about.

[davidfowl]

50%+ of the data in resource details is env vars that no one cares about.

That's a judgement, one I don't agree with. I don't know why you are calling it noise. It's literally what the resource implementation sets. Let's say I am trying to figure out why something isn't working. I go looking at env and I see nothing because we decided that information isn't important.

When you look at the env in docker inspect (in the UI) it's not being filtered.

[JamesNK]

When you look at the env in docker inspect (in the UI) it's not being filtered.

Aren't all those coming from the docker file? Docker itself isn't setting env vars and then showing them here.

[JamesNK]

I go looking at env and I see nothing because we decided that information isn't important.

We're already hiding env vars. Someone could already be confused that the env var set on their machine isn't showing up here.

Is the issue that hidden env vars (and resource properties) aren't discoverable?

What about improving the count displayed here?

It could be changed to "22 of 102". That indicates there are hidden env vars. The tooltip could then be enriched to say the "Show all" button can be clicked to toggle viewing all values. Or this UI itself could be become a button to toggle showing all on and off.

[davidfowl]

Probably? I ran the rabbitmq image, which has a docker file that I don't own (much like resources set env variables that the user didn't explicitly set).

We're already hiding env vars. Someone could already be confused that the env var set on their machine isn't showing up here.

I know and I think hiding system env variables is a good thing (that's actual noise). I don't like the idea of hiding anything else nor trying to determine what is a "user" set env vs a "library set env" based on some fuzzy logic that we start setting on our env variables.

[JamesNK]

I'm not proposing doing this for all env vars for libraries. It would just be done for the env vars that are automatically added to a .NET project resource. We know what those are and what their value would be. If they're present we simply don't show them by default.

[davidfowl]

Oh so you just want to special case a few env vars for .NET projects specifically?

[KennethHoff]

A more long-term solution could be a system for designating env. variables as "hidden" - similar to how files/directories starting with . are hidden by default on Unix systems - which can be shown by clicking for example an 👁️ icon.

This could be extended to apply to hidden resources (like the Dashboard itself), so one could temporarily view such resources, like for debugging.

[afscrome]

I agree that system variables should be hidden as they are there before aspire, and will be there if I dotnet run my app. However if Aspire adds any environment variables that could cause my app to behave differently when run through aspire vs dotnet run, I want aspire to tell me.

If your app already has jaeger & prometheus exporters set up, the OLTP_* variables will change how your app behaves (hopefully for the better in local dev). But it's still a change so I want aspire to tell tell me what it's doing differently.

[rosieks]

From developer perspective it would be great If I could see only variables that I have to provide manually when deploying application. I'm not there yet but I believe that some of OLTP_* I have to provide to make OpenTelemetry working (eg endpoint).