On Mon, Jul 16, 2012 at 6:50 PM, Emmanuel Lécharny <firstname.lastname@example.org>
Two servers can't have the same configuration, otherwise we have a problem !
- But i'm not against on replicating configuration completely. Some
Not completely as i say, they must be controlled through other repliccation
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
can use Karaf Cellar here. Cellar is used to keep multiple Karaf
synched in terms of Bundles,Features, and Configuration.(We can't use
configuration aspects because we're keeping our component
ApacheDS itself). I quickly looked through its functionality and
incomplete but promising. Most importantly it provides API to initiate
Karaf Instance replication.(Again not complete). So when replication
is revisited we can make use of Cellar.
- I looked at Apache ZooKeeeper a bit, and we should definetely
it in our LDAP replication system. It is simply a distributed data and
notification system for clusters. It has strength in node management
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.
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.
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.
Partial and fractional replication will come in handy here where we say this attribute or this entry does not get replicated and it does not. That simple.
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.
That's not something I'm feeling good about. We're going to change how we laid down the organization of configurations just for replication? Replication needs to advance to take into account these considerations instead of us injecting one offs to handle these replication scenarios.
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)
Please please please let's not fuck with this. This is the worst idea I've heard of yet. We don't need another one off here.
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.
I believe if
I don't believe simply keeping those 3 information local will help to make
we're gonna provide some way to replicate some ApacheDS instance's runtime
Unless the server can detect which configuration applies to itself.
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
have same runtime behavior, because they might have different
- Replicating ou=config is hell of a job because of site specific
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
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.