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

[Ludwig Krispenz]

On 06/05/2014 03:14 PM, Ludwig Krispenz wrote:
>
> 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.
looks like this could get ugly, if the topology info initialization 
would happen on several masters at the same time, they would create the 
same entries (at least the config root container) and we could get 
replication conflicts :-(
we need to be careful on the process, I have an idea how it could work, 
but need to think a bit more about it
>>
>>> 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.
>>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel