enhance `dapr run` to run multiple applications #6

mukundansundar · 2022-11-18T14:23:45Z

Signed-off-by: Mukundan Sundararajan 65565396+mukundansundar@users.noreply.github.com

Signed-off-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com>

mukundansundar · 2022-11-18T14:25:38Z

Open Question

Should dapr compose be renamed to something else?
Say project?

So the command becomes

dapr project up

We will have a project configuration file defaulting to dapr.yaml name in pwd.

0003-I-dapr-compose.md

akhilac1 · 2022-11-22T11:54:37Z

0003-I-dapr-compose.md

+
+Users developing different apps using dapr will have different resources/configurations that they use per application. Each time the user has to run the application with a particular config and resources directory value, they have to override the flag for `dapr run` command.
+
+Instead the following convention is proposed for loading the resources/config for an application.


Since this is about usage during development, if an app is part of a repo, too many transient files will be created. It would be good to give the user an option to set the root directory via an ENVIRONMENT VARIABLE

Could you explain this part @akhilac1?

0003-I-dapr-compose.md

akhilac1 · 2022-11-22T12:03:57Z

0003-I-dapr-compose.md

+
+### Constraints
+
+`compose` should mimic what `run` does for the most part. The defaults should not be different from `run` command with any new configuration options having sane documented least permissions based defaults.


Assuming default values will be provided for attributes like DAPR_HTTP_PORT, what is the mechanism for the user to identify this port, so that they could execute a HTTP request etc.? It would be good to document user experience for interacting with daprd launched with compose

We should be mounting these env vars on the user process.

Both DAPR_HTTP_PORT and DAPR_GRPC_PORT will be passed as env vars. I do not think metrics is port is needed inside the app, that can be part of the dapr compose output?

0003-I-dapr-compose.md

akhilac1 · 2022-11-22T12:10:37Z

0003-I-dapr-compose.md

+
+The logs will be as shown above, it will be chaotic to see what application is in which state and so on.
+
+Instead of writing to STDOUT, each application and associated `daprd` process will write the logs to `{application dir}/.dapr/logs/{app id}/app_{datetime}.log`, `{application dir}/.dapr/logs/{app id}/daprd_{datetime}.log`.


Is the user expected to look at the latest log to get the key attributes like DAPR HTTP PORT? This does not seem to be a good experience. Can you please check if key attributes required for the user to interact with Dapr and available as output of the dapr compose command?

Agreed ... That is what I was thinking as well.

nyemade-uversky · 2022-11-22T17:31:14Z

@dapr/maintainers-cli Putting this on your radar for 1.10

nyemade-uversky · 2022-11-22T17:33:41Z

0003-I-dapr-compose.md

+
+### Recommendation for 1.10
+
+- Initial implementation will only support Linux OS.


Suggested change

- Initial implementation will only support Linux OS.

- Initial implementation will only support Linux OS.

This should support both MacOS and Linux OS

0003-I-dapr-compose.md

yaron2 · 2022-11-22T19:27:04Z

0003-I-dapr-compose.md

+
+### Constraints
+
+`compose` should mimic what `run` does for the most part. The defaults should not be different from `run` command with any new configuration options having sane documented least permissions based defaults.


We should be mounting these env vars on the user process.

0003-I-dapr-compose.md

msfussell · 2022-11-23T06:11:03Z

0003-I-dapr-compose.md

+
+### Why dapr CLI?
+
+From the initial [proposal](https://github.com/dapr/community/issues/207), the solution was proposed as a seprate repo and CLI in itself. But later it was suggested to use dapr CLI itself to have a `compose` command in it instead of a having a separate CLI.


Using the word compose has so many connotation to Docker Compose, it leads to think this is only about running container. Given this is about mostly running processes I would use a different word, such as dapr start which carries not baggage and is clearer IMO

the only concern that I have here is, we would have too many start related commands.
dapr init, dapr start, dapr run.

Also dapr start does in no way convey that it is a command to start multiple apps in a single go.

msfussell · 2022-11-23T16:48:29Z

0003-I-dapr-compose.md

+
+### Subcommands and flags for `compose` command in CLI
+
+It is proposed to have a subcommand `up` in `compose` command to _bring up_ all the applications and daprd sidecars. Later on an extension can be added to _shutdown all_ application and sidecars with a `down` subcommand.


Why introduce the 'up' command and simply have just compose to start all the applications?

This was mostly following the same way docker compose, it will be familiar to the users.

mukundansundar · 2022-11-29T15:24:34Z

@yaron2 @artursouza @msfussell Based on the offline discussion that we had, we tentatively agreed to use dapr run -f . as the flag under which we will enable this feature and not under dapr compose. The main concern that I have with this is that, this is no longer an individual command and we will be modifying an existing command. Is that something that we want to go for? This proposal from start assumes that the command will be independent and will not affect any existing commands.

Thoughts?

yaron2 · 2022-11-29T15:28:02Z

I'm not concerned with changing the existing command, if the -f flag targets a completely different path. I think this is an implementation detail that shouldn't be discussed here - as far as the user experience goes, dapr run -f is the desired experience we'd like to see.

msfussell · 2022-11-29T16:12:13Z

I do like the approach of extending the existing dapr run command, which was why I questioned the need to have the up command. I suggest writing out full examples for using dapr run -f and dapr stop -f or dapr stop --all as this then builds on the current CLI commands.

mukundansundar · 2022-11-29T16:46:01Z

I do like the approach of extending the existing dapr run command, which was why I questioned the need to have the up command. I suggest writing out full examples for using dapr run -f and dapr stop -f or dapr stop --all as this then builds on the current CLI commands.

To summarize, the proposal should be modified to

not have process orchestration
extend dapr run to support running multiple files defined in an ingested "file"
define the file structure for the "file"
define a default directory struct for defining components to use with this feature
output logs to a file instead of STDOUT. (Let users know of file location for logs)

@yaron2 @msfussell @artursouza
Is this correct?

yaron2 · 2022-11-29T16:56:42Z

I do like the approach of extending the existing dapr run command, which was why I questioned the need to have the up command. I suggest writing out full examples for using dapr run -f and dapr stop -f or dapr stop --all as this then builds on the current CLI commands.

To summarize, the proposal should be modified to

not have process orchestration

extend dapr run to support running multiple files defined in an ingested "file"

define the file structure for the "file"

define a default directory struct for defining components to use with this feature

output logs to a file instead of STDOUT. (Let users know of file location for logs)

@yaron2 @msfussell @artursouza Is this correct?

LGTM.

Signed-off-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com>

yaron2 · 2022-12-01T19:36:35Z

+1 binding

mukundansundar · 2022-12-02T04:03:28Z

+1 binding

msfussell · 2022-12-05T15:45:43Z

I do like the approach of extending the existing dapr run command, which was why I questioned the need to have the up command. I suggest writing out full examples for using dapr run -f and dapr stop -f or dapr stop --all as this then builds on the current CLI commands.

To summarize, the proposal should be modified to

not have process orchestration

extend dapr run to support running multiple files defined in an ingested "file"

define the file structure for the "file"

define a default directory struct for defining components to use with this feature

output logs to a file instead of STDOUT. (Let users know of file location for logs)

@yaron2 @msfussell @artursouza Is this correct?

Agreed. LGTM

add dapr compose proposal

1b2c93a

Signed-off-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com>

mukundansundar mentioned this pull request Nov 18, 2022

Local Developer Experience - Run multiple dapr apps using dapr run -f dapr/cli#1123

Closed

6 tasks

akhilac1 suggested changes Nov 22, 2022

View reviewed changes

nyemade-uversky suggested changes Nov 22, 2022

View reviewed changes

yaron2 reviewed Nov 22, 2022

View reviewed changes

msfussell reviewed Nov 23, 2022

View reviewed changes

address review comments. remove process orchestration.

fa263aa

Signed-off-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com>

mukundansundar changed the title ~~add dapr compose proposal~~ enhance dapr run to run multiple applications Nov 30, 2022

rename file

b74b3d2

Signed-off-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com>

mukundansundar requested review from msfussell, akhilac1 and yaron2 November 30, 2022 08:19

remove restart field

1ea33fb

Signed-off-by: Mukundan Sundararajan <65565396+mukundansundar@users.noreply.github.com>

yaron2 approved these changes Dec 2, 2022

View reviewed changes

yaron2 merged commit f946492 into dapr:main Dec 2, 2022

mukundansundar deleted the run-multiple-dapr-apps branch December 2, 2022 07:49

mukundansundar mentioned this pull request Jan 20, 2023

Add capability to run to support -f flag dapr/cli#1161

Merged

3 tasks

mukundansundar mentioned this pull request Feb 15, 2023

Enhance dapr run -f to monitor started app processes dapr/cli#1190

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

enhance `dapr run` to run multiple applications #6

enhance `dapr run` to run multiple applications #6

mukundansundar commented Nov 18, 2022

mukundansundar commented Nov 18, 2022 •

edited

Loading

akhilac1 Nov 22, 2022

mukundansundar Nov 28, 2022

akhilac1 Nov 22, 2022

yaron2 Nov 22, 2022

mukundansundar Nov 28, 2022

akhilac1 Nov 22, 2022

mukundansundar Nov 28, 2022

nyemade-uversky commented Nov 22, 2022

nyemade-uversky Nov 22, 2022

yaron2 Nov 22, 2022

msfussell Nov 23, 2022 •

edited

Loading

mukundansundar Nov 28, 2022

karolz-ms Nov 29, 2022

msfussell Nov 23, 2022

mukundansundar Nov 28, 2022

mukundansundar commented Nov 29, 2022

yaron2 commented Nov 29, 2022

msfussell commented Nov 29, 2022

mukundansundar commented Nov 29, 2022

yaron2 commented Nov 29, 2022

yaron2 commented Dec 1, 2022

mukundansundar commented Dec 2, 2022

msfussell commented Dec 5, 2022


		Users developing different apps using dapr will have different resources/configurations that they use per application. Each time the user has to run the application with a particular config and resources directory value, they have to override the flag for `dapr run` command.

		Instead the following convention is proposed for loading the resources/config for an application.


		### Constraints

		`compose` should mimic what `run` does for the most part. The defaults should not be different from `run` command with any new configuration options having sane documented least permissions based defaults.


		The logs will be as shown above, it will be chaotic to see what application is in which state and so on.

		Instead of writing to STDOUT, each application and associated `daprd` process will write the logs to `{application dir}/.dapr/logs/{app id}/app_{datetime}.log`, `{application dir}/.dapr/logs/{app id}/daprd_{datetime}.log`.


		### Recommendation for 1.10

		- Initial implementation will only support Linux OS.


		### Why dapr CLI?

		From the initial [proposal](https://github.com/dapr/community/issues/207), the solution was proposed as a seprate repo and CLI in itself. But later it was suggested to use dapr CLI itself to have a `compose` command in it instead of a having a separate CLI.


		### Subcommands and flags for `compose` command in CLI

		It is proposed to have a subcommand `up` in `compose` command to _bring up_ all the applications and daprd sidecars. Later on an extension can be added to _shutdown all_ application and sidecars with a `down` subcommand.

enhance dapr run to run multiple applications #6

enhance dapr run to run multiple applications #6

Conversation

mukundansundar commented Nov 18, 2022

mukundansundar commented Nov 18, 2022 • edited Loading

Open Question

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nyemade-uversky commented Nov 22, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

msfussell Nov 23, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mukundansundar commented Nov 29, 2022

yaron2 commented Nov 29, 2022

msfussell commented Nov 29, 2022

mukundansundar commented Nov 29, 2022

yaron2 commented Nov 29, 2022

yaron2 commented Dec 1, 2022

mukundansundar commented Dec 2, 2022

msfussell commented Dec 5, 2022

enhance `dapr run` to run multiple applications #6

enhance `dapr run` to run multiple applications #6

mukundansundar commented Nov 18, 2022 •

edited

Loading

msfussell Nov 23, 2022 •

edited

Loading