On Wed, 07 Jan 2015 17:23:08 +0100 Ludwig Krispenz <[email protected]> wrote:
> > On 01/07/2015 05:13 PM, Simo Sorce wrote: > > On Wed, 07 Jan 2015 17:11:53 +0100 > > Ludwig Krispenz <[email protected]> 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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
