Howard Chu wrote:
HYC> I modified your test case to make it easier to run. HYC> The new test is in ftp.openldap.org:incoming/its5430.tgz.1
Looks good; thank you very much for this.
HYC> There were also some errors in your config file templates, HYC> which are corrected in the above archive.
HYC> Most notably, in template 1, you explicitly configured HYC> syncprov on top of glue instead of taking the default HYC> behavior of syncprov under glue. As documented in HYC> slapd.conf(5), you should only do that when you want a HYC> single syncprov overlay to be master of the entire tree. HYC> In this case, you clearly want syncprov to only master HYC> one portion of the tree, with the subordinate being HYC> taken care of by its own syncprov overlay.
That's a legacy of several previous iterations of the real project. Ideally each box would have at most two backends - one holding everything for which it's a consumer, and on the relevant machines a second backend holding the data for which it's master, then glue, then a single syncprov making the whole tree available. My colleague who implemented the first iteration did it that way and it should have worked, but the syncprov-glue interactions in 2.3.x were such that that resulted in sections of the tree not replicating and/or disappearing in various ill-defined situations.
Replicating each subordinate separately and gluing them together per-server was a hack; the default overlay ordering gave us visible entries of objectclass glue (and consequent missing subtrees) on some consumers, so we reversed them. It's imperfect but less imperfect than it was before ;-)
We will re-architect in the light of the recent changes to syncprov and glue. It has already been pointed out that big-picture discussion is noise on this list...
HYC> Not an error, but you used unique rids across all of the HYC> config files. rids only need to be unique within a single server.
I know. That's expediency in the config generator - it just increments a global counter each time it processes a consumer<-->provider relation. I'll make it more elegant next time round ;-)
Cheers
Duncan