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)?
Ralf
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. (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.)
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
-
Howard Chu -
Ralf Haferkamp