Re: s6-rc user experience question

[Ihor Antonov <ihor@antonovs.family>]

On 2022-10-17 13:11, Laurent Bercot wrote:
> 
>  No, because these are operations that are ideally done at different
> times.
>  - Compilation happens "offline", before you (re)boot the machine.
>  - s6-svscan is run independently from s6-rc, typically very early
> during the boot sequence. (Ideally it's process 1.) In any case the
> preexistence of a supervision tree is assumed by s6-rc, so spawning
> one as part of an s6-rc command isn't good workflow.
>  - Initialization happens when the service manager is ready to run,
> which means when the machine is online and already has an s6-svscan
> running.

I understand that these tools are executed at different times and we
want to make long-lived daemons as small as possible, that only do one
job. Perhaps a higher-level orchestration tool(s) is/are needed, that
will accomplish most typical workflows like:

- make changes in source -> complie -> switch symlink to latest compiled snapshot ->
  s6-rc-update. In systmd world this is easier: edit -> systemd
  daemon-reload

- list running services, start/stop them etc.

- auto-generating cooresponding logger service for a service. Today it
  is mostly a copy-paste job and incompatible with vanilla svcscan
  ./log/run subdir approach, which is confusing on its own.


Another set of reasons for a high-level utility is better UX:

- today users have to interact with multiple binaries and remember all
  their names, cli flags and positional parameters.

- there are no manual pages that would help with the point above, and
  short help messages are not very useful. ( I often resort to reading 
  https://skarnet.org/software/s6 from my browser )

- CLI interface of those binaries is not very intuitive, and there are
  no long options to improve readability in scripts. 
  Example: It is very hard to remember what this actually means
  
        s6-log -d3 -- t s16777216 n64 /var/log/mysvc

  I would much prefer something like this for all utilities, in
  addition to short options

        s6-log --notification-fd 3
               --num-files 64
               --filesize 16777216
               --timestamp tai64
                /var/log/mysvc


If changing CLI interface of s6 toolchest is not something that you
consider then a higher-level orchestration tool can take away some these
pains

>  However, there's a change I can make that would immediately improve
> s6-rc's usability: since it's largely a perception issue, changing
> the vocabulary from "s6-rc-compile" to "s6-rc-snapshot" and
> "compiled database" to "opaque snapshot of the set of services" would
> be a good idea. It would spook fewer people, and send fewer people
> into red herring trains of thoughts. :)

If compiled snapshot was an opaque file, instead of a directory that
would indeed make the perception a bit better