[Date Prev][Date Next]
Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- To: Pierangelo Masarati <email@example.com>
- Subject: Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Date: Tue, 22 Nov 2005 08:48:34 -0800
- Cc: OpenLDAP devel list <openldap-devel@OpenLDAP.org>
- In-reply-to: <1132676725.9350.17.camel@ando>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20498EEB4C91E6CD7543390E@cadabra-dsl.stanford.edu> <email@example.com> <0F84CCF877D1F094219160DC@cadabra-dsl.stanford.edu> <1132493739.3316.112.camel@ando> <F5A02675FC28DA7864C3438C@cadabra-dsl.stanford.edu> <1132505214.3316.117.camel@ando> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <1132590414.3330.4.camel@ando> <email@example.com> <firstname.lastname@example.org> <1132592221.3330.14.camel@ando> <1132594689.6044.6.camel@ando> <email@example.com> <1132657431.3354.61.camel@ando> <firstname.lastname@example.org> <1132676725.9350.17.camel@ando>
At 08:25 AM 11/22/2005, Pierangelo Masarati wrote:
>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.
I don't see the goal as "saving bandwidth" on this modify.
I see the goal as ensuring the slave is synced to the master
upon completion of this modify so that a subsequent read
by the client will see the results of its modify.
>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.
I think its flawed as it won't work properly when the slave and
master are not in sync (other mods have not yet been applied to
the slave). While you can certainly detect this case (by CSN
examination) and fail the modify, this seems counter productive.
Another problem is non-obvious side effects. For instance,
the modify could affect the visibility of other attributes.
For instance, consider:
and an access control on the master like:
access to filter=(publicAttributes=telephone) attr=telephone
by * read
That is, the slave's access to telephone is conditional.
Replying the modify won't have the side effect of making telephone
number visible to the slave, or worse, won't delete the telephone
number when the client deletes 'telephone' from publicAttributes.
>> >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).
I suspect that some of the syncrepl configuration could apply
in the chaining, but I also see it useful to keep them separate.
>> >> 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
>> 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
>Via Dossi, 8 - 27100 Pavia - ITALIA