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

Eugene Indenbom eindenbom at gmail.com
Fri Jul 9 11:52:00 UTC 2010


I am finishing testing updated IPA HBAC patch and pre-testing (whatever 
can be done in my setup) DYNDNS.
The rest is done. So patches will be available for review in a few hours.

On 07/09/2010 03:37 PM, Stephen Gallagher wrote:
> -----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-----
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel
>    




More information about the sssd-devel mailing list