Unable to manually start supporting dapr containers #1459
Description
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.