[SSSD] LDAP connection tracking, sharing and fail-over retry framework

Stephen Gallagher sgallagh at redhat.com
Fri Jul 9 11:37:44 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/08/2010 01:20 PM, Simo Sorce wrote
>  
> The point is that you never have any guarantee of consistency even
> against a single server when the connection does not drop, between
> different operations
> 
> We are not the only user of the server so between any 2 operations
> stuff can and do change.
> This is a fact of life we should better keep well in mind.
> We just have to deal with that.
> 
> This is also why I don't think that worries about "inconsistent" state
> make much sense.
> 

While this is a valid point, I think it's we're less likely to hit such
a race condition while talking to a single server than we are if we jump
around between servers.

>>  From my point of view we should go even further and not to store 
>> intermediate stage results to sysdb until all data is received from
>> LDAP server. Otherwise we could use inconsistent data in OFFLINE mode.
> 
> We will always risk suffering this no matter what you do, "consistency"
> is quite a loose concept in ldap when you get down to the operation
> level, because ldap has no transactions. Keeping all in memory would
> just waste a lot of memory without any real gain.
> 
> Please think again about this point, it is not as simple as you make
> it, and the assumptions you both are making are not valid.


Yeah, Simo makes a valid point here. Until LDAP supports transactions
(which will likely be never, since the plans to add them are tied up in
endless bureaucracy), we're probably better off just saving what we get
to the LDB when we get it.

As for the high-level sdap_op approach, I think we can all agree at the
least that it is a significant step forward from our current approach.
With that in mind (and plans to release 1.3.0 within the month) I think
we should continue with Eugene's work here for now. Tweaks for
efficiency can always be made in the future, but I'd very much like to
have reliable failover working in the short-term.

Eugene, most of your patches are acked on the list. We're just waiting
on patches that address the nitpicks on patches 0005-0007 and the more
sizeable fixes for 0011 (dynamic DNS).

I'm going to be going on vacation after today (starting roughly at 4
p.m. EST today), so I probably won't be able to test the dynamic DNS
fixes until I get back (unless you finish with them in the next few hours).

Once those patches are tested and acked, we'll get these all pushed
upstream and do a 1.3.0rc1 release and get some additional testing from
the community.


- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkw3CgcACgkQeiVVYja6o6NSQwCfUNyJlmjQLGtAW7afJ87MTn75
zxoAnAv3NiezZ2qpCqgkgJsbL1qziwe5
=TrW3
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list