[Spike] Spawn crc daemon on-demand

[cfergeau]

See #2454

This could be solved by having crc start the daemon automatically when needed, and the daemon shuts down automatically after a few minutes idle.

There are at least 2 ways of doing this, either crc takes care of the spawning/process monitoring/..., or we try to take advantage of preexisting OS facilities (systemd user services, launchd user daemons or agents, both need socket/on demand activationo).

[anjannath]

We need daemon to be running when a user tries to access any app routes deployed on the crc cluster, when the the daemon exits after some time am afraid these routes would also stop working? or socket activation would take care of this?

[cfergeau]

The daemon could keep running as long as the cluster is running, which would avoid this issue. It's when crc is not in use that I prefer the daemon not to be running, and thus to automatically exit when the cluster does not run.

[gbraad]

and thus to automatically exit when the cluster does not run.

Will the daemon therefore continuously perform status requests to the VM driver?

Because if the VM is not running, I would not like to see a failing tray (as it can't request the status; daemon stopped).

[cfergeau]

Will the daemon therefore continuously perform status requests to the VM driver?

This really is a long term goal, so no idea about this :) My feeling is that the daemon would store some cluster state, but would also monitor that the VM does not unexpectedly disappear.

Because if the VM is not running, I would not like to see a failing tray (as it can't request the status; daemon stopped).

The tray running may be one of the cases when the daemon has to be running, I don't know. But "starting the daemon on demand" implies that if the tray requests status from the daemon, then the daemon will be started automatically if it's not running yet.

[gbraad]

then the daemon will be started automatically if it's not running yet.

So this enhancement will not resolve the issue by itself ... so the lifecycle management needs to be handled in different places.

This could be solved by having crc start the daemon automatically when needed,

It is good to understand who needs the daemon to determine who starts what on-demand. While 'socket activation' is helpful, we first need to understand the needs

• crc needs the daemon for networking
• tray-windows and tray-macos need the daemon for status requests and starting crc'
• admin-helper receives calls from the daemon to setup DNS records (which have no need to run either without the VM/Daemon)

especially as not all platforms provide this functionality.

[cfergeau]

crc needs the daemon for networking

The way (maybe inaccurate) I see this is that it is the VM started by crc which needs the daemon for networking (and crc needs it for interacting with the VM).

admin-helper receives calls from the daemon to setup DNS records (which have no need to run either without the VM/Daemon)

This one is Windows-specific, on the other platforms admin-helper is a suid executable which is run when needed. I've been focusing on linux and to a lesser extent on macOS, so not much thought given to admin-helper (or Windows in general).