[Freeipa-devel] topology management question

[Ludwig Krispenz]

On 01/07/2015 05:35 PM, Simo Sorce wrote:
> On Wed, 07 Jan 2015 17:23:08 +0100
> Ludwig Krispenz <lkrispen at redhat.com> wrote:
>
>> On 01/07/2015 05:13 PM, Simo Sorce wrote:
>>> On Wed, 07 Jan 2015 17:11:53 +0100
>>> Ludwig Krispenz <lkrispen at redhat.com> wrote:
>>>
>>>>>>>> Now, with some effort this can be resolved, eg
>>>>>>>> if the server is removed, keep it internally as removed server
>>>>>>>> and for segments connecting this server trigger removal of
>>>>>>>> replication agreements or mark a the last segment, when tried
>>>>>>>> to remove, as pending and once the server is removed also
>>>>>>>> remove the corresponding repl agreements
>>>>>>> Why should we "keep it internally" ?
>>>>>>> If you mark the agreements as managed by setting an attribute on
>>>>>>> them, then you will never have any issue recognizing a "managed"
>>>>>>> agreement in cn=config, and you will also immediately find out
>>>>>>> it is "old" as it is not backed by a segment so you will safely
>>>>>>> remove it.
>>>>>> I didn't want to add new flags/fields to the replication
>>>>>> agreements as long as anything can be handled by the data in the
>>>>>> shared tree.
>>>>> We have too. I think it is a must or we will find numerous corner
>>>>> cases. Is there a specific reason why you do not want to add flags
>>>>> to replication agreements in cn=config ?
>>>> Simo and I had a discussion on this and had agreed that the
>>>> "marking" of a replication agreement
>>>> as controlled by the plugin could be done by a naming convention on
>>>> the replication agreements.
>>>> They are originally created as "cn=meTo<remote host>,..." and would
>>>> be renamed to something like
>>>> "cn=<local host>-to-<remote host>,....." avoiding to add a new
>>>> attribute to the repl agreement schema.
>>>>
>>>> Unfortunately this does not work out of the box. I only discovered
>>>> afetr implementing and testing (was not aware of before :-)
>>>> that DS does not implement modrdn operation for internal backends,
>>>> It just returns unwilling_to_perform.
>>>> And if it will be implemented the replication plugin will have to
>>>> be changed as well to catch the mordrdn to update the in memory
>>>> objects with the new name (which is used in logging).
>>>>
>>>> So, if there is no objection, I will go back to the "flag"
>>>> solution.
>>> What about simply deleting the agreement and adding it back with the
>>> new name ?
>> it will stop replication and the restart it again, unnecessary
>> interrupting replication for some time.
>> Assume you have a working topology and then raise the domain level
>> and the plugin becomes active,
>> creates segments and "marks" agreements as controlled. This should
>> happen as smooth as
>> possible.
> While this is true, it is also a rare operation. I do not see it as a
> big deal to be honest.
> However if you prefer to add a flag attribute that is fine by me too.
after thinking a bit more about it, I don't think we need the mark at 
all. The
agreement would have been marked in two scenarios
- the agreement exists and the dom level is raised, so that a segment is
   created from the agreement
- the dom level is set, the plugin active and a segment is addded to the 
shared tree
   so that a replication agreement is generated.
In all cases where an agreement is marked, there is a 1:1 corresponding 
segment,
so the existence of a segment should be marking enough.
I will make the mark_agreement and check_mark as noops, so if we really 
run into a
scenario where a mark would be required, it can be added in one of the 
methods discussed
so far.
>
> Simo.
>