On Fri, 09 Jan 2015 16:07:21 +0100 Ludwig Krispenz <[email protected]> wrote:
> > On 01/09/2015 03:50 PM, Simo Sorce wrote: > > 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 :) > 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. > 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. > > > > > -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
