directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Question about Replication of Config Partition and Schema Partition
Date Mon, 16 Jul 2012 15:50:17 GMT

>>       - 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.
Two servers can't have the same configuration, otherwise we have a problem !

There are very few informations that are not to be replicated, because 
they belongs to the local server (the three I mentionned : IP, port, and 
name). That means we need to find a better way to store those 
informations. And if we store them in the DIT, then this part of the DIT 
must *not* be replicated.

If this is what you were thinking of, then yes, I'm on the same page. 
May be we should put thos information somewhere else than on the 
ou=config sub tree (root DSE ?). We could specifically address those points.

I was pretty much thinking that we could store those informations in a 
plain text file, but that would be a bit overkilling, when we can store 
them in a the DIT too. Maybe storing those information sinto the 
ou=config entry could be the right thing to do, assuming that the 
ou=config is not replicated (we will only replicate what's under 
ou=config, ie, its children)

>>     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.
See upper with the suggestion I made about using pu=config entry but not 
replicating it. We could even extend the ObjectClass used to store the 3 
pieces of informations to store more, if needed. ATM, though, this is 
all what we need locally. Everything else can be safely replicated, 
assuming that the code that reads and handle the configuration knows 
that it must be combined with the logal configuration.

Emmanuel L├ęcharny

View raw message