On Fri, 09 Jan 2015 15:29:02 +0100 Ludwig Krispenz <[email protected]> wrote:
> > On 01/07/2015 05:35 PM, Simo Sorce wrote: > > 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. > 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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
