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.
How do you adequately encapsulate service categories, for instance? Do
you actually do any
testing (e.g. connect to socket to see if daemon providing service X is
up), or do you simply
have some sort of queue where you perform name lookups? Such as, mysqld
being up
causes the "database" name to be registered globally for all dependent
services to be aware?
But then what you're doing is poorly reinventing service discovery (like
Bonjour/DNS-SD, Consul,
etcd, SSDP and so on). Service discovery also implies you're dictating a
distributed architecture
with a particular configuration scheme (obtaining K-V pairs, or
whatever). Unless you check
"provides" using the file system, but that sounds clumsy, racy and again
superfluous.
And then actually trying to do service availability testing (e.g. via
connections)would require
a lot of explicit, brittle configuration.
But back to service categories, things like "database" are too generic.
You can have multiple
DBs of various types - relational, document-oriented, key-value store,
on-disk hash table
and so on. Such an approach isn't scalable *unless* you design your
platform in a
specific manner, by having the luxury (or arrogance) of dictating tons
of policy, as CoreOS
can do, for instance.
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.
Or you just order your services descendingly in the dependency chain,
yet again.
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.
