Re: What to do with test058?

[Ralf Haferkamp <rhafer@suse.de>]

Am Freitag 11 November 2011, 11:05:28 schrieb Howard Chu:
> Ralf Haferkamp wrote:
> > Hi,
> > 
> > I wonder how we should go forward with test058-syncrepl-asymmetric.
> > If I understand the test (and the comments in syncrepl.c)
> > correctly the setup it is testing is unsupported in slapd, am I
> > right? (Which is the reason why test failures are ignored
> > currently, I guess)
> > 
> > On the provider the syncprov overlay is setup for the glued
> > database and the consumer's syncrepl clients (also glued) are
> > configured on the individual child databases. Additionally the
> > consumers have configure the the syncprov overlay also of the
> > topmost database. AFAICS all of the failures that test058 reports
> > are related to this unsupported config.
> > 
> > Is anybody planning to work on adding support for such a setup. Or
> > should we just rework the test to a supported scenario (or even
> > remove it completely)?
> 
> No plans, but it's probably worth thinking about supporting it.
So how could support for this look like? One problem is that the 
consumers compute their sync cookies from the glued db's contextcsn 
attribute (at least if the glued db has the syncprov overlay loaded). 
This leads to the race problem upon consumer startup (I think) and also 
to the problem that the initial sync for newly added consumer databases 
does not work in such a setup.

One possible solution might be to store the contextCsn separately for 
every db, even if the syncprov overlay is added to the glue database. 
This would of course require special handling for consumers replicating 
the complete glued tree.

Or how about having every consumer store its individual cookie separately 
from the contextcsn (e.g. in a subentry)?

> (Patches welcome.) Gluing different types of contexts together seems
> to be a pretty important capability anyway, and in general our support
> for multiple contexts is weak. (E.g., ITS#6942.)

Ralf