On 01/22/2015 01:00 PM, Avery Payne wrote:
> This is what I tried to accomplish with the script-driven approach,
> using a "pull" rather than a "push". Each service definition only
> knows what it "needs"; nothing else is furnished. Needs are a
> directory in the definition named "./needs", and in that directory, a
> symlink pointing to each service definition that fulfills a "need".
> As a service definition starts, it asks for those "needs" to come up;
> if they can't, then the definition can't come up and is considered to
> be failing. When the definition asks for a "need", it does so by
> using a standard "servicetool up needed-service" command; it has no
> visibility of what is going on and frankly doesn't care. This was
> about as plain as I could make it, yet still work. Looking beyond
> known concerns about "is the service really up" it has some
> advantages: it's fairly clean, low-overhead (only 1 symlink per need),
> it doesn't care much about broken or missing "needs" (because that
> triggers a failure anyways), it naturally builds dependency chains
> without having to explicitly spell them out, it can handle "trees" of
> dependencies, it handles instances where common leaf-nodes in a tree
> of dependencies won't clash, etc. And the best part, this structure
> has the potential for re-use with a dedicated dependency manager, such
> as nosh, or the upcoming extensions to s6 - the information is
> unambiguous and clear, but no policy is set by doing it this way,
> beyond defining what is inside of "./needs". So you could use this at
> a high or low level, and make it fly.
So in essence it's the same as the need(8) approach described in Richard
Gooch's
"Linux Boot Scripts" paper?
http://www.safe-mbox.com/~rgooch/linux/boot-scripts/
This is indeed simplest. It saves a lot of effort in startup ordering,
but it's also
insufficiently expressive. You're only offering hard dependencies,
which, if simple,
still opinionate and restrict the general framework into a narrow direction.
It has been my feeling that the optimal service supervision scheme would
eschew
the concept of a dependency system completely, and instead rely on some form
of lazy/delayed execution, performing heavy use of queueing with no explicit
dependency configurations whatsoever. I know inetd/ucspi-tcp can provide
this effect to a limited degree, but its use hasn't been too impressive
thus far
(systemd has overhyped it significantly). Alternative ideas still escape
me, but
I'm trying to research concepts from related fields like distributed systems
(provisioning, service discovery, clusters, 9P/namespaces/Plan 9, so forth)
in the hope of coming up with something.
I'm having a hunch it'll involve setting up a way for daemons to communicate
by a superserver through the use of a persistent data store (be it a file
server, a task queue or whatnot). Starts to border on service discovery, but
simpler and more ad-hoc.
In general, the idea is to provide a mechanism for synchronization that will
displace dependencies, getting the same intended result.
Received on Thu Jan 22 2015 - 18:20:29 UTC