Server Daemon UX

[idagelic]

Is your feature request related to a problem? Please describe.

Minor changes to the daemon command set. The current way the Daytona Server is being daemonized might be slightly confusing at first glance. This is what the commands do now:

daytona server - runs the server in the current terminal session daytona server -d - registers, starts the daemon process daytona server stop - stops, unregisters the daemon process daytona server restart - stops, unregisters, registers, starts daemon process

Daemonized state should be the default way to run the server and starting and stopping the server shouldn't always register/unregister the systemd/launchd service. Also, this makes the service autostart on boot which should be an optional feature.

Describe the solution you'd like

Use the "serve" verb for a Server running in the current terminal session if someone prefers that approach Separate the registering/unregistering and starting/stopping commands Add a enable/disable command - using the same naming as systemd

Proposed format:

daytona serve - runs the server in the current terminal session daytona server - registers and starts the daemon process

daytona server start - starts the daemon process daytona server stop - stops the daemon process daytona server restart - restarts the daemon process

daytona server init - registers the daemon process (alias daytona server register) daytona server destroy - unregisters the daemon process (alias daytona server unregister) daytona server reload - stops, unregisters, registers, starts the daemon process

daytona server enable - enables the daemon on startup daytona server disable - disables the daemon on startup

Additional notes Also add the line "To view logged information use daytona server logs -f" to the command starting the daemon

[vedranjukic]

My suggestion is to use the server command to start the server process in the foreground. For managing the daemon we can use the daemon command:

daytona daemon start - registers the daemon if not already registered and starts the daemon. daytona daemon stop - stops the daemon daytona daemon restart - stops and starts the daemon daytona daemon remove - stops the daemon if running and unregisters the daemon daytona daemon enable - enables the daemon on startup daytona daemon disable - disables the daemon on startup

[metcalfc]

I would have enable as the registration mechanism and have start, stop, restart only handle daemon state. If someone wants to manage the service externally through ansible or other IaC tool, they can manage the server loop however they want (systemd or other).

If users want that handled for them, then they'd

daytona daemon enable
daytona daemon disable

If start handles the registration as well there is no way to manage that on your own and you'd have to fight with the daytona daemon.

[metcalfc]

@vedranjukic and @idagelic I'm just now upgrading to v0.8.2 and its really painful. In part because of the automatic and magic systemd work. This is not how most Linux services do this and its super confusing and makes me feel like my system has been hijacked. Daytona has a couple of places we try to make it easier for the new user and it ends up making the life of a regular user more difficult (https://github.com/daytonaio/daytona/issues/252#issuecomment-2021060164)

Here is my recommendation as a long time SRE/DevOps/SysAdmin. I didn't rename the command to daemon. It is a server process that can be run in -d daemon node. Like ngnix or whatever. Since the binary is the CLI and the server, it seems to make sense to keep this under server.

daytona server
daytona server -d

Are the ways to manually launch daytona. When in daemon mode we can add nice op sugar commands like:

daytona server stop
daytona server restart # effectively daytona server stop && daytona server -d
daytona server start # alias to daytona server -d

If folks want the magic automatic systemd foo we can add:

daytona server enable
daytona server disable

My expectation is that we eventually have system packages. MSI/DMG for Windows and Mac with signed binaries and real integrations into the services systems of those platforms.

On Linux for "real" deployments folks will want packages (rpm/deb). In which case we can have

daytona-cli
daytona-server

daytona-server is just a package that depends on the CLI and also includes the systemd unit file.

Its fine to optimize for the individual dev and support them with enable/disable but we should not fight with or traditional Linux server admin approaches.

[vedranjukic]

I agree on this. We should not do unexpected system changes.

daytona server enable
daytona server disable

is a good idea.

[vedranjukic]

daytona serve is a good idea to prevent confusion with the daemon process.

As for registering the daemon, we should ask the user for confirmation if the -y flag is not provided. Eg. the user should be aware that daytona will register the service.

On the other hand, I don't think we should do enable/disable as these actions should be done by the OS service manager.