[Freeipa-devel] topology management question

[Simo Sorce]

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.

Simo.

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