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.
