cli icon indicating copy to clipboard operation
cli copied to clipboard

feature/podman: Updating dapr cli to allow different container runtime

Open martin-bucinskas opened this issue 3 years ago • 12 comments

Description

Adding a new argument --container-runtime to be passed during dapr init and dapr uninstall commands. This allows a user to provide a container runtime environment such as podman where in some instances docker is unavailable.

This would be used to stand up a repeatable Dapr environment with the placement, zipkin and redis containers in the desired container runtime environment.

The default container runtime is docker, therefore the behavior is unaltered unless we provide podman as the runtime.

Example:

# Install Dapr using podman as container runtime
$ dapr init --container-runtime podman

# Uninstall Dapr using podman as container runtime
$ dapr uninstall --cotnainer-runtime podman

Issue reference

closes #257

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

  • [x] Code compiles correctly
  • [ ] Created/updated tests
  • [x] Extended the documentation

martin-bucinskas avatar Apr 04 '22 22:04 martin-bucinskas

Thanks for this PR! Notice that build/tests are failing.

yaron2 avatar Apr 05 '22 18:04 yaron2

Thanks for this PR! Notice that build/tests are failing.

@yaron2 Thanks, I didn't assume that this may break the e2e tests, I'll have a look at them when I have a chance.

martin-bucinskas avatar Apr 05 '22 18:04 martin-bucinskas

@yaron2 Standalone e2e tests are passing in the dev-container: image

The lint issues fixed too for the build action: image

martin-bucinskas avatar Apr 05 '22 21:04 martin-bucinskas

@martin-bucinskas Thanks for this PR ... we will review it soon ...

mukundansundar avatar Apr 06 '22 04:04 mukundansundar

@martin-bucinskas Could you fix the conflicts in the PR ? Thanks ...

mukundansundar avatar Apr 08 '22 01:04 mukundansundar

@martin-bucinskas Please comment /assign on #257 to assign the issue to yourself.

mukundansundar avatar Apr 08 '22 03:04 mukundansundar

I am also thinking should the direct commands that are run from standalone.go uninstall.go etc be abstracted away with an interface, struct and receiver functions? Thereby each implementation can have its own code and only the interface is used for calling? This would also make the code potentially more testable ...

cc @yaron2 @artursouza thoughts on this?

mukundansundar avatar May 02 '22 10:05 mukundansundar

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!

dapr-bot avatar Jun 01 '22 15:06 dapr-bot

@martin-bucinskas Can you update the PR to resolve conflicts and address comments?

mukundansundar avatar Jun 06 '22 06:06 mukundansundar

@martin-bucinskas Can you update the PR to resolve conflicts and address comments?

mukundansundar avatar Jul 13 '22 05:07 mukundansundar

@martin-bucinskas @mukundansundar I am planning to take this forward by resolving the conflicts and review comments. I will take the commits and create a new PR. @martin-bucinskas Let me know if you still planning on completing this.

pravinpushkar avatar Aug 08 '22 17:08 pravinpushkar

@martin-bucinskas @mukundansundar I am planning to take this forward by resolving the conflicts and review comments. I will take the commits and create a new PR. @martin-bucinskas Let me know if you still planning on completing this.

More than happy to, I've been quite busy lately and haven't been able to get back into this. It would be much appreciated!

martin-bucinskas avatar Aug 08 '22 17:08 martin-bucinskas

@martin-bucinskas thanks for the PR. This work has been included in #1041

mukundansundar avatar Aug 23 '22 16:08 mukundansundar