dashboard
dashboard copied to clipboard
Dapr dashboard doesn't show local app-only components
In what area(s)?
/area runtime
What version of Dapr?
1.5.1
Expected Behavior
I have installed Dapr using the slim option dapr init -s
because I want to be very specific about what services are available to various applications I'm working on. For example, we don't have Zipkin in our Kubernetes cluster so I don't want that just "globally available" during local development.
I have an application set up with exactly one component - a file-based secret store. I also have a configuration specified to disable tracing. I'll show these in the repro below.
I am able to start my application using the dapr
command line and it starts fine. It runs and I can access the app. I don't get the errors saying Zipkin is unavailable so I can tell the config is working.
However, when I do dapr dashboard
and look at the components tab, I don't see my secret store component. I don't see any components. If I view the configuration tab, I see the one at ~/.dapr/config.yaml rather than the one for my app.
There are no namespaces available in the "scope" dropdown in the top right corner. "All" is the only option.
I am able to find my running application in the dashboard. The associated components and config are not there.
I expect to be able to at least find the components and config for running apps when browsing the dashboard.
Actual Behavior
The local components and configuration are not shown in the dashboard.
Steps to Reproduce the Problem
Using .NET 6:
dapr uninstall --all
dapr install -s
mkdir DaprRepro
cd DaprRepro
dotnet new web
mkdir components
echo "{}" > secrets.json
Create the file config.yml
and put it in the DaprRepro
folder. Make it like this:
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: dapr-config
spec:
tracing:
samplingRate: "0"
In the components
folder, create keystore.yml
and save this:
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: key-store
spec:
type: secretstores.local.file
version: v1
metadata:
- name: secretsFile
value: secrets.json
Now run the app.
dapr run `
--app-id "daprrepro" `
--app-port "4801" `
--components-path "./components" `
--config "./config.yml" `
-- `
dotnet run `
--urls "http://localhost:4801"
If you look in dapr dashboard
now, you'll see the app but no components. The config is also wrong and doesn't show the correct sample rate.
Release Note
RELEASE NOTE: FIX Local application components and configuration now show in the dashboard.
This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.
I've never been entirely clear about bots closing issues automatically without some sort of team response. This is still an issue. It might not be something that folks care to address but it seems like a human should make that decision.
@tillig thanks for keeping this issue alive - as you can see, the bot removes the stale
label as soon as someone responds in the issue so it won't be closed. This is to make sure that only inactive issues are closed, and even then these can be reopened later by maintainers.
I am moving this issue to the correct repository.
Additionally whenever I start a dapr process with a components folder with a space in the name, then the dapr application is not shown.
E.g. when I run
dapr run --app-id myapp --components-path "Local Components"
then the app "myapp" is not shown in the running dapr apps.
When I run
dapr run --app-id myapp --components-path "LocalComponents"
then the app "myapp" appears in the list with running dapr apps.
dapr --version
CLI version: 1.7.1
Runtime version: 1.7.2
any solutions now?...
For anyone else having this issue right now: The problem is with dapr cli parsing the command line. It is fixed in the main branch for dapr cli but that's not yet released.
https://github.com/dapr/cli/pull/1244
The problem appears as soon as any "flag" parameter is used when starting dapr for example "--app-ssl". As the CLI parses the command line into key value pairs this results in everything after that not getting recognized (including app-id) as it's off by one step. A workaround for me was to use another "flag" parameter like "--enable-app-health-check" to make it trip again resulting it to be back in the correct order for the following arguments.
I had a similar problem when using docker compose, where the components would not be detected if they were .yml
files.
Changing them to .yaml
worked.