Proposal: Deprecate dora up

[phil-opp]

The dora up command starts local coordinator and daemon instances as background processes. This is convenient for getting something up quickly, but is has considerable drawbacks:

• Users don't see any stdout/stderr of the daemon and coordinator instances
  • We are currently in the process of migrating all the daemon/coordinator output to log messages, which will pass them to dora start --attach instances. However, not all dataflows have an attached CLI and merging all the outputs in a single terminal windows can lead to confusion too.
• We don't see whether the daemon/coordinator is still running or not.
  • You have to check the task manager or similar.
• There is no obvious way to kill a coordinator/daemon running in the background.
  • There is dora destroy, but this does not work for unresponsive instances.
  • Task manager works, but feels hacky.

Running the dora daemon and dora coordinator commands in extra terminal windows avoids these drawbacks. You see all of their stdout/stderr, you see their error if they crashed, and you can kill them through CTRL-C.

The only real advantage of the dora up command is that it makes it easier to quickly run a local dataflow. However, this still isn't optimal, so we're discussing ways to make it easier to run local dataflow in #698. Once we implement a proposal like the dora run subcommand, there is in my opinion no good reason to use dora up anymore.

Because of this, I propose to deprecate the dora up command once we have some good alternative way of running local dataflows.

Drawbacks

• The dora up command is used a lot in our current documentation, so deprecating it would be a change that affects most users.

[haixuanTao]

Ok for this as well!