Re: [ldapext] nfsv4 vs the ldap consistency model

[simo <idra@samba.org>]

On Fri, 2008-11-21 at 13:18 -0800, Howard Chu wrote:
> Leif Johansson wrote:
> > On Friday 21 November 2008 21:49:30 Howard Chu wrote:
> >> Leif Johansson wrote:
> >>> So I had a talk with the nfsv4 wg today (and on their list earlier). The
> >>> are trying to build AFS-style volume location for NFS using LDAP and I
> >>> think they may have a problem with the LDAP consistency model: i.e
> >>> "eventually consistent" for a couple of their usecases.
> >>>
> >>> I won't go into details unless people particularly care but I think we
> >>> may need an I-D (something for a bof in SF perhaps) describing a control
> >>> which asks for the result of an update operation to be  delayed until a
> >>> certain criterion (eg in the form of a compare condition) is fulfilled on
> >>> all "slaves". Implementation details would differ depending on the
> >>> precise way replication is done for that vendor.
> >>>
> >>> Does that sound like something you would
> >>>
> >>> a) barf at
> >>> b) laugh at
> >>> c) ignore
> >>> d) review given that someone wrote it up?
> >> Sounds like what's really wanted is a distributed transaction. Why not just
> >> call it that?
> >
> > Not really - I don't think they need commit/rollback or the ability to modify
> > multiple entries in a transaction.
> 
> Then my answer is (a) and (b).
> 
> You cannot guarantee that the update will succeed at all slaves, so 
> abort/rollback is essential.
> 
> This is 2 phase commit, whether they think they want to handle multiple 
> entries or not. In reality they are modifying multiple entries anyway, even if 
> it's the "same" entry on each slave. This is a transaction, plain and simple.

This is a "distributed" transaction, something that is even more complex
to guarantee then just a transaction at single server level.

Can we get first the reason why they want to do something like that ?

It seem to me that way too many premises are wrong on a request like
this, from thinking only in term of "slaves", to thinking that all
"slaves" can always be reached by a specific master and so on.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo@samba.org>
Senior Software Engineer at Red Hat Inc. <simo@redhat.com>

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext