* Laurent Bercot <ska-skaware_at_skarnet.org> [20150425 03:10]:
> Bundles are great. You can define a bundle for every possible combination
> of services if you're so inclined (it's still 2^n, so don't overdo it, but
> yeah).
This means that a service can be part of more than one bundle right?
> >What I like with aa-enable is that servicedirs are created from a source
> >servicedir and some config data. So one can have a single openvpn_at_
> >source servicedir, and use it to create different servicedirs with
> >different configs. There's also the bits to easily use the same logger,
> >but also service-specific log script...
>
> s6-rc-compile actually generates the servicedirs from the source data,
> which isn't exactly a servicedir - it contains run and finish scripts,
> but also additional information. I haven't settled on a format yet, if
> for instance instantiability is important I'll think about supporting it.
FWIW, I do believe instantiability is an important feature: it enables
the common use case administratively scaling the ability to serve
independent but similar services (a.k.a. "virtual" hosting, or
"multi-tenant").
> >The wants dependencies are just a way to pull a service without failing
> >if that service fails to start, some sort of "optional dependency" I guess.
> >E.g. one could say that php only wants sqld, so even if the later can't
> >be started the website can work, and everything that doesn't need db
> >will work, the rest failing with db connection errors, instead of having
> >no website at all.
>
> I see. With s6-rc, you would just make a "web" bundle, containing "httpd"
> and "php", and a "web+sqld" bundle, containing "web" and "sqld". You would
> launch web+sqld, and even if sqld fails, httpd and php are still brought up.
Remember to put this example in the documentation ;)
> >Separating order & dependency also allows to set up some order in
> >services in case, but without the need for them to be actual
> >dependencies, which may also be handy for source servicedirs to plan for
> >different uses/configs.
>
> Do you have a real-life example ? I can imagine how that can be useful,
> but a dependency manager is complex enough as is, and I don't want to
> add more complexity if there's no real, actual use for it that cannot
> be achieved another way.
I believe the motivation here is easy of use: the ability to re-use
service definitions for different setups. It's similar to the "wants"
dependencies: it's easier to setup a configuration with wider purposes
if "wants" is supported.
As I see it it's a "nice-to-have": it need not be in an initial release,
but it should be in the roadmap since it is not required but useful
feature.
qvb
--
pica
Received on Sat Apr 25 2015 - 09:46:18 UTC