* Laurent Bercot <[email protected]> [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@ > >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
