On Sun, Jul 15, 2012 at 2:03 AM, Emmanuel Lécharny <elecharny@gmail.com> wrote:
Le 7/14/12 9:13 PM, Göktürk Gezer a écrit :
Hi Devs,

Here i share my findings on LDAP replication in terms of OSGI layer.

    - First of all i found nothing related to replicating configuration of

    LDAP Server on any RFC related to replication. So replicating configuration
    is only ApacheDS's concern because it keeps its configuration as DIT data.
Absolutely. RFC 4533 says nothing about how to implement replication nor how to manage the replication configuration.
Means more room for better management ! 

    I don't know OpenLDAP yet but don't think its the same, right?
It's clearly different, but not that much.

And i
    believe we shouldn't let administrators to initiate replication under
    ou=config base. It is not standart and it is not wise.
The ida we had was to manage configuration using an Administrative Area. This is not yet implemented though, so we ended up with managing replication under ou=config atm.
I believe ou=config serves the purpose more or less.

Simply replicating
    configuration will first break the replication aggreement between servers
    anyway ! You should set some filters on config partition entries to whether
    replicate them, but this would be improper in terms of design IMO.
Whe you setup replication, you tell the local server with which remote server you want to replicate. Obviously, you don't want to replicate such localized information. Now, you can still consider that we share a global configuration between all the servers, in which you just name each server, with the assoictaed informations (IP, port, etc), and now you can setup a replication mechanism in which you express each configration using thoses names. For instance, if you have 3 servers A, B and C, you may have the shared configuration where A -r> B, B-r> C, B-r>A. This configuration can be replicated as is on , B and C, because each server will now which replication is of interest to itself.
Apache ZooKeeper would provide so much help for these kind of scenarious.
    - But i'm not against on replicating configuration completely. Some one

    would want to simply clone the server in its entirety. ( This is not
    touched by RFC as i see ) Because our OSGI distribution is Karaf based, we
    can use Karaf Cellar here. Cellar is used to keep multiple Karaf instances
    synched in terms of Bundles,Features, and Configuration.(We can't use its
    configuration aspects because we're keeping our component configurations in
    ApacheDS itself). I quickly looked through its functionality and code. It's
    incomplete but promising. Most importantly it provides API to initiate
    Karaf Instance replication.(Again not complete). So when replication system
    is revisited we can make use of Cellar.
    - I looked at Apache ZooKeeeper a bit, and we should definetely leverage

    it in our LDAP replication system. It is simply a distributed data and
    notification system for clusters. It has strength in node management in
    clusters and good for implementing infrastructure related parts of
    replication system.

So i see no threat to OSGI from LDAP Replication. However i believe
ou=config should be excluded from replication in any scenario.
Not sure.
Not completely as i say, they must be controlled through other repliccation system. I say they shouldn't be managed by LDAP replication, because as i said: 2 server having the same configuration are not have to have same runtime behaviour because of the different bundle configurations.
  I believe if
we're gonna provide some way to replicate some ApacheDS instance's runtime
layout, we should not do it by LDAP Replication. Because :

    - It is not just config partition manages the server anymore.
    - We just can't be sure that 2 server having the same configuration will

    have same runtime behavior, because they might have different composition
    of bundles.
    - Replicating ou=config is hell of a job because of site specific
    configuration parameters.
Unless the server can detect which configuration applies to itself.

Bottom line, there are a very litte set of information a server needs to keep local :
- its IP address
- its port
- its name

The name will be used to identify the configuration that applies to the local server.
I don't believe simply keeping those 3 information local will help to make replicating configuration information across multiple nodes consistent. When thinking in terms of some system, there will be always some more local configuration points other than IP/port/hostname IMO. 

Emmanuel Lécharny