Re: Could s6-scscan ignore non-servicedir folders? [provides-needs deps]

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Thu, 22 Jan 2015 10:00:19 -0800

On 1/22/2015 9:08 AM, post-sysv wrote:
> On 01/22/2015 01:33 AM, Avery Payne wrote:
>> This brings to mind the discussion from Jan. 8 about "./provides",
>> where a defining a daemon implies:
>>
>> * the service that it actually provides (SMTP, IMAP, database, etc.);
>> think of it as the "doing", the piece that performs work
>>
>> * a data transport (pipe, file, fifo, socket, IPv4, etc.); think of
>> it as how you connect to it
>>
>> * a protocol (HTTP, etc.); think of it as a grammar for conversing
>> with the service, with vertical/specific applications like MySQL
>> having their own grammars, i.e. MySQL-3, MySQL-4, MySQL-5, etc. for
>> each generation that the grammar changes.
>>
>> I'm sure there are other bits and pieces missing. With regard to
>> relationships, if you had a mapping of these, it would be a start
>> towards a set of formal (although incomplete) definitions. From that
>> you could say "I need a database that speaks MySQL-4 over a file
>> socket" and you could, in theory, have a separate program bring up
>> MySQL 4.01 over a file socket when needed.
>>
>> But do we really need this?
>
> The provides-needs relationship is one I've pondered myself (and it's
> how GNU dmd works),
> but once again it stumbles conceptually the more I think of it.
Which is why I asked if we really need this. I tried really hard to
think of a good use case, and the only one I could come up with is
similar to what you describe - basically, this would be used in
conjunction with some kind of super-server.
> Once again, provides-needs can be adequately hacked in by doing
> "start-single-instance foobard ||
> exit 1", something to the effect of it. You're adding a thin and
> useless layer of sugar just to avoid
> mixing some code with your configuration.
I'm not even sure we need to have much code to support this - see below.
>
> Or you just order your services descendingly in the dependency chain,
> yet again.
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.
> Provides-needs would work fine for a service-oriented architecture
> with explicit design and policies,
> but in a generic supervision framework it just sounds unwieldy. Do try
> to describe a model where
> it isn't, though.
I think the concept of a "needs" has a future, provided that it is close
to what I described above. But "provides" becomes a lot more vague the
more I look at it.
Received on Thu Jan 22 2015 - 18:00:19 UTC