On Fri, Sep 15 2017 at 09:09:19 +0200, Michael Ströder scribbled in "Re: Olc deployment vs slapd.conf based deployment":
Quanah Gibson-Mount wrote:
I think it's a strong plus to be able to reconfigure a standalone server into an MMR cluster with zero downtime,
I don't buy this argument. If you're really eager reaching high availability you have to implement a decent load-balancer and test correct fail-over anyway. And then your MMR cluster will have zero down-time (seen from the LDAP clients) during re-configuration even when restarting the replicas one after another.
Ciao, Michael.
I'm rather split between the two configuration options, but I agree that Quanah's example is not the best -- it's not the type of operation that is likely to be done regularly enough to make it important in the greater scheme of things.
I really do like the idea of being able to tweak and update the configuration without needing to HUP slapd (it's a shame there's no "reload" option, in addition to "restart"), especially for things like updating ACLs that are usually considered trivial/standard changes.
That said, I'm also a really big fan of plain text configuration files, centrally managed in a version controlled repository, and pushed/pulled around to systems as needs be. We use this mechanism for _all_ of our infrastructure estate and knowing that I can make a change _in_one_place_, and roll it out to "N" slapd hosts simply, really does help me sleep at night.
Compared to that, having to run ldapadd/ldapmodify on all those hosts is an awkward proposition.
What's missing, before we can seriously consider using slapd-config for production environments, is an administrative interface that fills the gap between the two configuration styles. We're far from being opposed to writing our own tools (much of our infrastructure management tooling is bespoke, just like any workplace with a hint of complexity) and indeed, looking at how to best integrate slapd-config based configurations is on my todo list for when our shipment of round tuits is delivered.
That said, I can't help thinking, however, that it would be more approachable to newcomers if, ideally, there was some functionality to assist environments like ours, without having to write it all in house.
Stating that slapd-config is not a flat-file system is a little unfair too, given that it's on disk in LDIF format (even if it should left alone). Our config management system can build LDIF using templating (can't they all?), the issue is running a diff against that, and the running cn=config, and applying the changes cleanly, idempotently, and atomically -- is there anything that will fill the pre-flight `slaptest` role when support for slapd.conf is removed?
Cheers.
Dameon.