Idea #6884
Updated by Brett Smith over 8 years ago
This is a planning story. The expected outcome is more well-specified stories. Background: Right now our install docs usually suggest you use runit to supervise daemon processes. This has several downsides: * It repeatedly complicates the install instructions with infrastructure that could be added to the packages directly. * runit is unfamiliar to many users, which adds to the difficulty of system deployment and maintenance. * runit is not readily available on CentOS 6, and possibly other versions. Questions the planning process should answer: * What supervisors inits do we need to support? I assume sysvinit and systemd. It's probably relatively easy to support runit since we have most of the scripts written already. Any others? Ubuntu 12.04 has Upstart, but apparently with some level of sysvinit compatibility, which makes it seem lower-priority to me. compatibility. * How should we Should our packages try to support multiple supervisors? One option that seems to have inits simultaneously, or should each package support is to have the package install a script for init that ships with the distro's native init, but include other distribution? * Is there some fpm-like tool we can/should use to generate different init scripts in @/usr/share/doc@ (or wherever). for us? We can consider other options. (I think Nico was investigating something along these lines.) * [Others? See the discussion starting at "6663 note 30":https://arvados.org/issues/6663#note-30 for some deployment background and desired functionality.] It would be cleanest to have a separate story for every daemon package, although hopefully once we have one or two under our belts, the rest will go much more quickly. h2. Implementation notes Nico has investigated using pleaserun to generate scripts. Generally it makes templates that you'd rather check in to Git and maintain by hand. Trying to coax it to generate scripts that are ready for production seems like more trouble than it's worth. The goal is to have all of these read necessary configuration from the same place; e.g., a configuration file in @/etc/default@ or @/etc/sysconfig@.