Using syncrepl in single slapd instance.

[Laurence Field <Laurence.Field@cern.ch>]

I have been investigating the use of syncrepl as a replacement for the 
mechanism we are currently using in our system and become stuck.  Here 
is the scenario to put the problem in context.
Within our infrastructure there is the order of 1000 Grid services each 
of which runs its own LDAP server that contains information about its 
structure and state under the DN mds-vo-name=resource,o=grid. Each 
institute that that operates a Grid service (in the order of 300 
distributed globally), runs an LDAP server containing the consolidated 
information from all services within its domain under the DN 
mds-vo-name=site-name,o=grid.
In addition, there are about 70 top-level LDAP servers distributed 
globally that contain the consolidated information from all sites using 
the DN mds-vo-name=local,o=grid.
At the moment the LDAP databases are updated externally via process that 
polls the LDAP server for all information, which is very inefficient. 
Syncrepl seems to be a better mechanism to use however, I am having 
difficulty with one scenario.  Using standard syncrepl with a relay, the 
site-level LDAP server can be configured with the following slapd.conf 
file.
http://lfield.web.cern.ch/lfield/bdii-slapd.conf-basic-rep

However, the site LDAP server is a Grid service and needs to publish 
itself.  If I try to  just to an LDAP add I get the following message, 
which I guess is due to the fact that this part of the database is now 
"owned" by the syncrepl process.
ldap_add: Server is unwilling to perform (53)
   additional info: shadow context; no update referral

I tried to work around this problem by using another database and some 
more relays the result of which can be seen in the following file.
http://lfield.web.cern.ch/lfield/bdii-slapd.conf

However, this result with the following error, which suggests that I 
can't "mask" a database with a relay that points somewhere else.
bdii-slapd.conf: line 69: <suffix> namingContext 
"Mds-Vo-name=resource,o=internal" already served by a preceding bdb 
database serving namingContext "Mds-Vo-name=resource,o=internal"
Does anyone have an example of how to do a syncrepl where a single slapd 
instance can act as both the consumer and producer?
Also, has anyone done any scalability/reliability tests with syncrepl?

Thanks,

Laurence