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

[Dmitri Pal]

On 06/05/2014 01:12 PM, Simo Sorce wrote:
> On Thu, 2014-06-05 at 16:46 +0200, Ludwig Krispenz wrote:
>> 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 :-(
> This is exactly why I said I do not want the plugin to create the
> topology tree itself :-)
>
> It should only import agreements that are not yet there. There is still
> potential conflict, the topology plugin will have to handle them, by
> intercepting replication writes to the topology tree and smartly
> merging/fencing IMO.
>
>> 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 am all ears.
>
> Simo.
>
We already have several situations (CRL, DNSSEC, cert rotation) where a 
single server has to do the job first and all the rest should rely on that.
We can simply our life by making the initialization a special admin 
initialized operation for the situations when we upgrade from earlier 
versions.
So general topology plugin does not initialize anything automatically. 
If we build a new deployment the ipa replica management tools will drive 
the modifications as servers are added.
If it is an upgrade admin might go to IPA configuration and ray 
build/rebuild topology. This will drop all segment information if there 
is any and using master list from cn=masters connect to each replica, 
query its replication agreements and create data for the replicated 
tree. If some replica is not on line the operation will report that 
replica can be connected and that topology is not complete.
I think this is acceptable for topology plugin to focus only on keeping 
data in sync when replica management tools are invoked and mot worry 
about initialization after migration.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.