[389-devel] 389-DS plugin: need some help on the design

thierry bordaz <tbordaz@xxxxxxxxxx> · Wed, 24 Sep 2014 12:33:00 +0200



    Hello,

      
    I was
        investigating the alternative/impacts of a new plugin and I
        would like to share some thoughts and check I did not miss
        something important.

        
        Here is the description of the problem we want to address. In
        MMR topology, we have an entry containing a single valued
        attribute. It is an integer syntax attribute. Our need is that
        the attribute can only be increased. So if its initial value is
        5, an update MOD/REPL '6' is valid and applied, while MOD/REPL
        '3' is invalid and rejected/ignored. Also being in MMR, the
        attribute can be updated on several instances. 

        
        The current approach is to create a BE_PREOP or BE_TXN_PREOP
        plugin. This allow to retrieve the current value from the pblock
        (SLAPI_ENTRY_PRE_OP) and guaranties the value is exact as only
        one operation is processed at a time.

        
        The plugin  registers a mod operation callback. It controls the
        new_value vs current_value to check that  new_value
        >current_value. The plugin will update the mods. In
        particular translates a MOD/REPL into a MOD/DEL(current value) +
        MOD/ADD(new_value).

        
        Regarding the change of the MODS (mod/repl -> mod/del +
        mod/add), the plugin should be a BE_PREOP. This is because MODS
        are applied after BE_PREOP plugins, then new MODS added by
        BE_TXN_PREOP plugins are applied. A BE_TXN_PREOP plugin may
        translate mod/repl -> mod/del+mod/add but it is too late,
        mod/repl has already been applied after BE_PREOP plugins were
        called.

        
        Regarding replication, for non replicated updates, it should
        just reject (unwilling to perform) ops with new_value <
        current_value.

        For replicated update I see the two cases ([server / csn / attribute
        value] ): [A/csnA/valueA],
        [B/csnB/valueB] and the expected final value is ValueB+csnB
      
        csnA < csnB
            and ValueA < ValueB. 
        
          When server A
              receives csnB/valueB, this is fine as ValueB>ValueA.
              But to know that ValueB will be selected  the plugin needs
              to check that csnB>csnA.
        
        
          When server B
              receives csnA/valueA it has 3 possibilities:
          
            reject
                (unwilling to perform) the update. But then replication
                A->B will fail indefinitely
            erase the
                update. For example the plugin could erase the mod from
                the set of mod. 

              
            let the
                operation continue because csnA < csnB, the kept
                value will be ValueB. Here again the plugin needs to
                check csnA vs csnB
          
        
        csnA > csnB
            and ValueA < ValueB. 

          
          When server A
              receives csnB/valueB, this is fine as ValueB>ValueA.
              But to know that ValueB will be selected  the plugin need
              to check that csnB>csnA.
          When server B
              receives csnA/valueA it has 2 possibilities:
          
            reject
                (unwilling to perform) the update. But then replication
                A->B will fail indefinitely
            erase the
                update. For example the plugin could erase the mod from
                the set of mod. 

              
      So I think the plugin
        should not rely on the new_value present in the operation but
        rather  computes the final_value (taking into account the CSN).

        If the final_value > current_value, it let the operation
        going on (even if the new_value in the operation <
        current_value). If the final_value < current_value it should
        remove the mod from the mods (2.2.2) and likely log a message.

        
        Changing MOD/REPL into MOD/DEL+ MOD/ADD is a possibility but the
        attribute being single valued I think it is not mandatory.

        
        Thanks

        thierry

        
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel