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

[Ludwig Krispenz]

On 06/05/2014 02:45 PM, Simo Sorce wrote:
> On Thu, 2014-06-05 at 11:27 +0200, Ludwig Krispenz wrote:
>> On 06/04/2014 06:04 PM, thierry bordaz wrote:
>>> 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.
> Agree.
>
>> 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).
> Nope, leave re-initialization to the plumbing. The topology plugin deals
> only with topology, it should not be involved with re-initializations,
> save for not going crazy and trying to remove agreements "during" a
> re-initialization.
>
>> 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.
> Yep.
>
>>   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
> This is my preferred, although leaves the problem open for migration, we
> need a way to properly prime the topology so that it doesn't wipe out
> current agreements before they are imported.
>
>> "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 would like some more details about what you have in mind here,
> depending on the fine points I might agree this is desirable to solve
> the migration problem.
I will write it down for a few different scenarios.
>
>> 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.
> Full topology information you mean here, right ?
topology information (nodes and edges) and properties of the 
connections, eg replicated or stripped attributes
>
> Simo.
>