[Freeipa-devel] topology management question

[Simo Sorce]

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 :)

> 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.


-- 
Simo Sorce * Red Hat, Inc * New York