-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to manually start supporting dapr containers #1459
Comments
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. |
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. |
Bonk. |
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. |
Bad bot. |
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
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.The text was updated successfully, but these errors were encountered: