Slow progress & plans

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Thu, 9 Oct 2014 14:35:29 -0700

As expected, the runit-scripts project is slow moving. Real life and all
of those other things that intrude prevent me from forging ahead full
steam. :) The template system is coming along nicely, along with a
de-facto standard for handling their storage and linkage:

run templates are in sv/.run
finish templates are in sv/.finish
log templates are in sv/.log
service-specific process flags are stored in sv/(service)/options

There are over a dozen "simple" service definitions now in the repository
with more on the way. Of course you can use any other directory name
besides just sv (should a framework need it).

The options file is new, and while it adds a bit of overhead, it makes some
sense as well. It standardizes a location for all of the process-specific
flags (i.e. "--some-process-flag" that needs to be passed to the program),
makes it into a text file for easy searching/processing (example: grep
"--myoption" sv/*/run), is process-specific, lives alongside the associated
service scripts for easy management, and also has a small hook for pre-exec
needs.

Lastly, some of the definitions (ok, a lot of them) haven't been fully
tested yet. I've left a "untested" empty file in the definition directory
to indicate that there isn't any feedback yet on if it works properly
(although I know that the simple template is in fact working correctly
because I've tested it and the resulting service startup). As I have time
to test, or receive feedback, adjustments will be made and the untested
file removed.

I like Laurent's proposal for logging, specifically the "graceful failover"
aspect. Eventually I would like to integrate it, but for now I think the
"selector template" pattern should suffice.

Finally, I am giving serious though to merging this into a single set of
supervise-style scripts and have it work "transparently" between the
various frameworks. It would look a bit wild when working with it (lots of
bits and files everywhere) but it would also allow all of the frameworks to
simply "plug and go".

As usual, comments, hints, constructive criticism are all welcome.
Received on Thu Oct 09 2014 - 21:35:29 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:18 UTC