<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/25/2014 04:32 AM, Rich Megginson
wrote:<br>
</div>
<blockquote cite="mid:54237ECA.4010505@redhat.com" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 09/24/2014 04:33 AM, thierry
bordaz wrote:<br>
</div>
<blockquote cite="mid:54229DDC.80806@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<font face="Times New Roman, Times, serif">Hello,<br>
<br>
</font>
<blockquote><font face="Times New Roman, Times, serif">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.<br>
<br>
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. <br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
Regarding replication, for non replicated updates, it should
just reject (unwilling to perform) ops with new_value <
current_value.<br>
For replicated update I see the two cases </font><font
face="Times New Roman, Times, serif">([server / csn /
attribute value] ): </font><font face="Times New Roman,
Times, serif">[A/csnA/valueA], [B/csnB/valueB] and t</font><font
face="Times New Roman, Times, serif">he expected final value
is ValueB+csnB</font>
<ol>
<li><font face="Times New Roman, Times, serif">csnA <
csnB and ValueA < ValueB. </font></li>
<ol>
<li><font face="Times New Roman, Times, serif">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.</font></li>
</ol>
<ol>
<li><font face="Times New Roman, Times, serif">When server
B receives csnA/valueA it has 3 possibilities:</font></li>
<ol>
<li><font face="Times New Roman, Times, serif">reject
(unwilling to perform) the update. But then
replication A->B will fail indefinitely</font></li>
<li><font face="Times New Roman, Times, serif">erase the
update. For example the plugin could erase the mod
from the set of mod. <br>
</font></li>
<li><font face="Times New Roman, Times, serif">let the
operation continue because csnA < csnB, the kept
value will be ValueB. Here again the plugin needs to
check csnA vs csnB</font></li>
</ol>
</ol>
<li><font face="Times New Roman, Times, serif">csnA >
csnB and ValueA < ValueB. <br>
</font></li>
<ol>
<li><font face="Times New Roman, Times, serif">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.</font></li>
<li><font face="Times New Roman, Times, serif">When server
B receives csnA/valueA it has 2 possibilities:</font></li>
<ol>
<li><font face="Times New Roman, Times, serif">reject
(unwilling to perform) the update. But then
replication A->B will fail indefinitely</font></li>
<li><font face="Times New Roman, Times, serif">erase the
update. For example the plugin could erase the mod
from the set of mod. <br>
</font></li>
</ol>
</ol>
</ol>
<font face="Times New Roman, Times, serif">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).<br>
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.<br>
</font></blockquote>
</blockquote>
<br>
<font face="Times New Roman, Times, serif">What happens if ValueA
== ValueB and csnA != csnB? Do we want to allow the same value
to be issued by two different servers? Is this a case as with
DNA and uidNumber, that we assign servers to have ranges?<br>
</font></blockquote>
<br>
<font face="Times New Roman, Times, serif">That is a good question
and so far I still need confirmation.<br>
This is a case with OTP updating the HOTPcounter/TOTPwatermark.<br>
If a bind happens with a given new HOTPcounter value, it will
trigger internal mod on an entry (related to bindDN) to update
this counter.<br>
IMHO we can have parallel bind with a same counter, this on
different or on the same server as well. In both cases, the csn
will be different but the value identical.<br>
<br>
thanks Rich<br>
thierry<br>
</font>
<blockquote cite="mid:54237ECA.4010505@redhat.com" type="cite"><font
face="Times New Roman, Times, serif"> <br>
<br>
</font>
<blockquote cite="mid:54229DDC.80806@redhat.com" type="cite">
<blockquote><font face="Times New Roman, Times, serif"> <br>
Changing MOD/REPL into MOD/DEL+ MOD/ADD is a possibility but
the attribute being single valued I think it is not
mandatory.<br>
<br>
Thanks<br>
thierry<br>
<br>
<br>
</font></blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
389-devel mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:389-devel@lists.fedoraproject.org">389-devel@lists.fedoraproject.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/389-devel">https://admin.fedoraproject.org/mailman/listinfo/389-devel</a></pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
389-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:389-devel@lists.fedoraproject.org">389-devel@lists.fedoraproject.org</a>
<a class="moz-txt-link-freetext" href="https://admin.fedoraproject.org/mailman/listinfo/389-devel">https://admin.fedoraproject.org/mailman/listinfo/389-devel</a></pre>
</blockquote>
<br>
</body>
</html>