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. I don't know OpenLDAP yet but don't think its the same, right? And i believe we shouldn't let administrators to initiate replication under ou=config base. It is not standart and it is not wise. 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.
- 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. 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.