[Freeipa-devel] Move replication topology to the shared tree

[thierry bordaz]

On 06/04/2014 05:41 PM, Simo Sorce wrote:
> On Wed, 2014-06-04 at 13:46 +0200, Ludwig Krispenz wrote:
>> On 06/04/2014 10:43 AM, thierry bordaz wrote:
>>>> So my proposal would contain the following components
>>>>
>>>> 1] Store replication configuration in the shared tree in a
>>>> combination of server and connection view (think we need both) and
>>>> map replication configuration to these entries. I would prefer a
>>>> direct mapping (with a subset of the cn=config attributes and
>>>> required additions)
>>> About adding a new server in the replication topology.
>>> If it was initialized, it may register itself into the shared tree and
>>> then join the topology. If it was not initialized, it can be
>>> initialized online by one of the master. Will it be triggered with an
>>> update to the shared tree ?
>> I think this has to be decided, I proposed some kind of bootstrapping:
>> If the topology plugin is enabled and started it would check if there is
>> already info on the connections for this server and if not create/update
>> the entry in the shared tree, this could also happen if a new server is
>> added.
> You mean updating the shared tree from information about replication
> agreements found in cn=config ?
> I can see how this would be useful in migration from previous server
> versions, but I fear would cause issues if you remove a connection when
> one of the 2 servers is down.
> When you bring the server up it would try to re-create a connection that
> was deleted by the admin. It's a catch-22 which is why I want the shared
> tree to be authoritative but not the cn=config tree.
>
>> But Simo wanted to have the info in the shared tree indepndent of what
>> was already configured.
> It's not much about being independent, it's about what is authoritative
> and what is not.
>
>> One problem with the automatic approach is what should be done if the
>> config differs on the already deployed servers
> That's just one of many problems.
> I think cn=config entries should be read an injected in the shared
> topology only once at upgrade time, but not anymore after.
> Maybe this calls for adding nodes to the topology tree, if the topology
> plugin starts and the server is not in the topology tree, then it
> sources the local configuration, then adds itself and the connections to
> the topology tree.
> If the node is already in the topology tree this step is always skipped.
I like the idea that the node can add itself and the connection to the 
topology tree.
But this requires that the node database is already initialized (have 
the same replicageneration than the others nodes).
If it is not initialized, it could be done by any masters. But if it is 
automatic, there is a risk that several masters will want to initialize it.

In addition if the new node has a different replicageneration, how does 
the new node know that it should wait to be initialized rather than 
initialize the others.
>
> Or something similar (could be just a flag in cn=masters objects).
>
> makes sense ?
>
> Simo.
>