[Freeipa-devel] topology management question

[Ludwig Krispenz]

On 01/09/2015 04:18 PM, Simo Sorce wrote:
> On Fri, 09 Jan 2015 16:07:21 +0100
> Ludwig Krispenz <lkrispen at redhat.com> wrote:
>
>> On 01/09/2015 03:50 PM, Simo Sorce wrote:
>>> On Fri, 09 Jan 2015 15:29:02 +0100
>>> Ludwig Krispenz <lkrispen at redhat.com> wrote:
>>>
>>>> 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.
>>> We discussed this already and we came to the conclusion we need
>>> it :)
>> ok, I think in the discussion we came up with the mark was with my
>> concerns about
>> removing a replica, and you more or less destroyed my concerns.
>> I agree there could be some corner cases like the ones you sketch
>> below. But it will still be difficult to do the right thing in all
>> cases. Take your example of a marked agreement and no segment. we
>> could arrive at this state
>> in two different scenarios:
>> 1]
>> -  take a backup of the shared database
>> - add a segment, a RA will be created and marked
>> - the database gets corrupted and you restore the backup
>> - the agmt is marked and no segment exists - should we really delete
>> the agmt ?
> Yes.
> The shared tree is the authoritative repository. If you restore you
> are required to do due diligence and check what was lost and restore
> that too.
ok, if we agree on this, we need the mark , convinced again:-)
>
>> 2]
>> -  have a segment and a marked agreement
>> - take a backup of the dse.ldif
>> - delete the segment, agmt is removed
>> - restore the dse.ldif,
>> - the agmt is marked, no segment exists
> Yes, this is the scenario I was hinting at, it the agreement is marked
> we know it is not something we need to import (it was already imported)
> so we just go on and delete it.
>
>>>> 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.
>>> I recall the problems came in corner cases. Like when a replica
>>> starts and finds an agreement.
>>> If it is marked and a segment does not exist, we simply delete it.
>>> However if it not marked and a segment does not exist, what do you
>>> do ? Without markings you can only import it, and this way you may
>>> end up reviving deleted agreements by mistake.
>>>
>>> The reason this may happen is that cn=config and the main database
>>> are separate, and a backup dse.ldif may be use upon start even
>>> though the shared database had been already updated, so we cannot
>>> count on the replica starting and finding the
>>> segment-to-be-deleted-via-replication still there.
>>>
>>> The marking was needed to make sure that once an agreement was
>>> imported we wouldn't do it again later on.
>>> I still maintain that marking it is safer and will lead to less
>>> issues with phantom segments coming back to life.
>>>
>>> Simo.
>>>
>>>
>
>