[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

On Tue, 2005-11-22 at 07:34 -0800, Kurt D. Zeilenga wrote:
> 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.

I think this somehow misses the point of "saving bandwidth" by avoiding
the consumer -> producer -> consumer path of modifications that enter
the shadowed system from a consumer.  In principle what you suggest is
the "right" thing, but then we'd have only half of the advantages this
feature can bring.  What I'm trying to understand is whether it is
correct to assume that if the "assert" with just the above mentioned
attrs returned by the pre/post reads when "locally applying the
change" (as opposed to "syncing") is bullet proof or flawed.  To me, it
doesn't sound flawed, but I admit I didn't think too much about it, and
I'm not a real sync expert.

> >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.

OK, let's get that as well; now, you might object the master might add
further operational attributes we need to sync, but then it would be
just a matter of configuring what attributes must be appended to the
postread; such a setup doesn't necessarily need to be a black box, it
may allow some admin intervention to setup things (much like syncrepl
configuration, which allows "attrs", "filter", "scope" and so).

> >>   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 concur, but see above.

> >
> >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.

I didn't consider that.  OK, it sounds fair enough.

> >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. 



Ing. Pierangelo Masarati
Responsabile Open Solution

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it