Skip to content

Unable to manually start supporting dapr containers #1459

Open
@atrauzzi

Description

@atrauzzi

In what area(s)?

Not sure?

What version of Dapr?

1.14.1

Expected Behavior

Ideally some kind of command in the dapr CLI that can start supporting infrastructure, perhaps like: dapr --runtime-path="./" start-infrastructure

Actual Behavior

If I clean all my systems containers or wish to work on an existing project that already has a .dapr directory, I have no way of starting all the supporting infrastructure.

Steps to Reproduce the Problem

mkdir test
dapr --runtime-path="./" init
# stop and delete all dapr support containers to simulate change

# Scenario 1
dapr --runtime-path="./" init
# (some error about it already existing)

# Scenario 2
dapr --runtime-path="./" ?????
# There's no command to start support containers

Rationale

When I use dapr locally for development, I need to be able to switch between dapr installations. My workstation represents not one, but the potential for unlimited dapr setups. I can't assume that whatever dapr init did the one time I ran it is necessarily going to be forever.

This is why I make use of the --runtime-path option when running the dapr cli.

On a separate note, this also has me curious about upgrade scenarios? If a new version of dapr comes out, how do I upgrade without having to delete and then recreate my .dapr directory?

My whole reason for saving the .dapr directory to a separate path other than my home dir is because it's also where I define all my components. If I'm creating local development setups, I need some way to ship the component definitions.

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind/bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions