Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:03 AM 11/22/2005, Pierangelo Masarati wrote:
>On Mon, 2005-11-21 at 11:13 -0800, Kurt D. Zeilenga wrote:
>> In theory, the slave could attach a post-readEntry control to
>> chaining operation wrapping the the modify request and use
>> the returned entry to "pre-sync" the value.
>
>We'd need a pre-read to fetch the pre-modify current CSN and entryUUID,
>in order to understand if the modification can be directly applied to
>the local database,

Don't 'apply the modify', instead "sync to the result of the modify".
Hence, only post-read is needed.

>and a post-read to fetch the newly assigned CSN and
>modifyTimestamp (and entryUUID, in case of add), to build up the local
>modification (we already know the modifiersName).

You do not necessarily know the name the master will
use as the modifier.


>>   Of course,
>> syncrepl would then need to ignore changes to that
>> entry that have an later CSN.

If you sync to the result, the slave can ignore pre-existing CSNs.


>I think this implicit in syncrepl, because as soon as this independent
>operation syncs the CSN, syncrepl should understand it doesn't need to
>process it futher.  Although I didn't consider the issue deep enough
>yet, there shouldn't be any chance of an intermixing modification, since
>we are performing it only if the CSN of the original and of the shadow
>copy were the same, and we get the new CSN after the modification
>directly from the producer, so there cannot be any change in between.
>The only issue I see is if (but, how?) another change gets to the
>producer right after, and sync takes place before the local modification
>is performed.  But this wouldn't yet be an issue, because if the local
>modification fails, eventually syncrepl will line-up the shadow entry,
>so we plainly need to ignore failures in the local modification.
>
>> 
>> Note that use with a chaining operation is necessary here
>> for two reasons:
>>         1) to avoid conflict with any client provided read
>>         entry control, and
>>         2) appropriate authorization (e.g., as slave not
>>         client).
>
>Well, the modification should be chained to the consumer as the client,
>so that appropriate access control takes place; the local modification
>should be performed as the replicator identity.  So I agree with point
>(1), but not with point (2),

The problem is that the read control will be process as the
client's id, not the slave's id.  The read control must be processed
as the slave's id as the client id might not be authorized to
read what the slave needs.  By placing the read control in
the outer chaining operation, the read is requested under the
appropriate authorization.

If you don't use a chaining operation, you need to do separately
read the results.

>because if the consumer is a shadow of the
>producer, we should be able to assume that whoever should be able to
>write to the consumer should also be able to write to the producer.  Of
>course, we might not be able to rebind as the client (unless simple bind
>was used), so we'd rather need to assert its identity (I guess this is
>part of the devil you mentioned :).  In any case the operation needs to
>be chained. 
>
>What's the status of operation chaining?  Where should I start looking
>at?

The I-D might presently be expired, but that doesn't mean you
shouldn't start looking at it.  We need to push this stuff
forward through "early", "experimental" implemention. 


>p.
>
>
>
>
>
>Ing. Pierangelo Masarati
>Responsabile Open Solution
>
>SysNet s.n.c.
>Via Dossi, 8 - 27100 Pavia - ITALIA
>http://www.sys-net.it
>------------------------------------------
>Office:   +39.02.23998309          
>Mobile:   +39.333.4963172
>Email:    pierangelo.masarati@sys-net.it
>------------------------------------------