On Sun, Jul 15, 2012 at 2:03 AM, Emmanuel Lécharny <email@example.com>
Le 7/14/12 9:13 PM, Göktürk Gezer a écrit :
Absolutely. RFC 4533 says nothing about how to implement replication nor how to manage the replication configuration.
- First of all i found nothing related to replicating configuration of
Here i share my findings on LDAP replication in terms of OSGI layer.
LDAP Server on any RFC related to replication. So replicating configuration
is only ApacheDS's concern because it keeps its configuration as DIT data.
Means more room for better management !
It's clearly different, but not that much.
I don't know OpenLDAP yet but don't think its the same, right?
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.
believe we shouldn't let administrators to initiate replication under
ou=config base. It is not standart and it is not wise.
I believe ou=config serves the purpose more or less.
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.
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.
Apache ZooKeeper would provide so much help for these kind of scenarious.
- But i'm not against on replicating configuration completely. Some one
- I looked at Apache ZooKeeeper a bit, and we should definetely leverage
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.
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
So i see no threat to OSGI from LDAP Replication. However i believe
ou=config should be excluded from replication in any scenario.
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.
Unless the server can detect which configuration applies to itself.
I believe if
- It is not just config partition manages the server anymore.
we're gonna provide some way to replicate some ApacheDS instance's runtime
layout, we should not do it by LDAP Replication. Because :
- We just can't be sure that 2 server having the same configuration will
- Replicating ou=config is hell of a job because of site specific
have same runtime behavior, because they might have different composition
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.