dapr run fails after airgap dapr init

[shivamkm07]

Expected Behavior

After airgap dapr init, dapr run should work fine

Actual Behavior

Airgap dapr init creates components files pubsub.yaml and statestore.yaml in the default components folder and also adds tracing spec in default config file which uses zipkin. But redis and zipkin ain't packaged in bundle and so dapr run fails after airgap init

Steps to Reproduce the Problem

dapr uninstall --all
dapr init --from-dir <path_to_bundle_folder>
dapr run

The output of dapr run looks like this:

WARNING: no application command found.
ℹ️  Starting Dapr with id myapp. HTTP Port: 37783. gRPC Port: 33469
ℹ️  Checking if Dapr sidecar is listening on HTTP port 37783
INFO[0000] starting Dapr Runtime -- version 1.7.0 -- commit 3c4510a685470eb8a5403e9d9a451bc93e67e6c4  app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] log level set to: info                        app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] metrics server started on :39655/             app_id=myapp instance=shivamlaptop scope=dapr.metrics type=log ver=1.7.0
INFO[0000] standalone mode configured                    app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] app id: myapp                                 app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] mTLS is disabled. Skipping certificate request and tls validation  app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] local service entry announced: myapp -> 172.25.113.68:42263  app_id=myapp instance=shivamlaptop scope=dapr.contrib type=log ver=1.7.0
INFO[0000] Initialized name resolution to mdns           app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] loading components                            app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
WARN[0000] error initializing pub sub pubsub.redis/v1: redis streams: error connecting to redis at localhost:6379: dial tcp 127.0.0.1:6379: connect: connection refused  app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
WARN[0000] process component error daprd process will exited, gracefully to stop  app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] dapr shutting down.                           app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] Stopping Dapr APIs                            app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0000] Waiting 5s to finish outstanding operations   app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
INFO[0005] Shutting down all components                  app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
FATA[0005] process component pubsub error: redis streams: error connecting to redis at localhost:6379: dial tcp 127.0.0.1:6379: connect: connection refused  app_id=myapp instance=shivamlaptop scope=dapr.runtime type=log ver=1.7.0
❌  The daprd process exited with error code: exit status 1

Possible Solution

Airgap init shouldn't add the pubsub and statestore yaml files in components folder and tracing spec in config file.

Release Note

RELEASE NOTE: FIX Bug in Airgap Dapr Init

[mukundansundar]

@shivamkm07 AirGap init should have the same set of files that are init for slim init and not the ones that are done for normal init ...

[mukundansundar]

A mitigation step for now is to remove the tracing related fields in the config file but keep that file and remove the pubsub and state-store yaml files.
Another mitigation can be to start Redis and Zipkin in Docker and leave the configuration files as such.

docker run --name "dapr_zipkin" --restart always -d -p 9411:9411 openzipkin/zipkin
docker run --name "dapr_redis" --restart always -d -p 6379:6379 redis

[mukundansundar]

@artursouza @yaron2 Since air gap init is in preview, I would like to mark this as P1 and not a P0 for hot fix. Any issues with that?

[dapr-bot]

This issue has been automatically marked as stale because it has not had activity in the last 30 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.