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

[Ludwig Krispenz]

On 06/04/2014 06:04 PM, thierry bordaz wrote:
> 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.
I would not give the plugin the power to reinitialize a database on 
another server and I also would not put the responsibility to do it to 
the plugin. Initializing a server is an administrative task done at 
specific steps during deployment or in  error conditions and most time 
has to be scheduled and often on-line initialization is not the 
preferred method.
The plugin could still be used to trigger online initializations if the 
nsds5replicarefresh attribute is part of the information in the shared 
tree, it can be modified, the plugin on the targeted server will detect 
the change, update the replication agreement object and start the 
initialization (but this should probably still be allowed to be done 
directly).

The question for me was more how the configuration information in the 
shared tree is initialized (not the full shared tree).
We do agree that the info in the shared tree should be authoritative. To 
synchronize the info in the shared tree and cn=config I see two modes:
"passive" mode: the sync is only from the shared tree to cn=config, it 
is the responsibility of an admin/tool to initialize the config in the 
shared tree
"supporting" mode: if the plugin starts, it checks if the info in the 
shared tree exists, if not it initializes the topology info in the 
shared tree and then only reacts to changes in the shared tree.
I prefer the "supporting" mode (if we find a better name), as long as no 
admin interferes the info in the shared tree and cn=config will be 
identical as they are set in a normal deployment, so no harm is done, 
but they are replicated and the full information is available on every 
server.
>
> 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.
>>
>