Hi,
I would like to ask for opinions about:
https://fedorahosted.org/sssd/ticket/3126
The basic idea is that the responder would choose what kind of optimization
would the back end perform when saving the sysdb entries. Requests that
just return information might choose to optimize very aggressively (using
modifyTimestamp) and requests that actually authenticate or authorize the
user might choose to not optimize at all to avoid issues like the ones we saw
with virtual attributes that don't bump the modifyTimestamp attribute at all.
On the responder side, this is quite easy, just send an additional flag
during the responder request. It's the provider part I'm not so sure
about, because there the optimizations are performed at the sysdb level.
So far I can only think about extending sysdb_transaction_start() (or
providing sysdb_opt_transaction_start and letting the old
sysdb_transaction_start default to no optimization) which would
internally keep track of the active transaction and the optimization we
want to perform. Since only sssd_be is the cache writer and there is
only one cache per domain.
Additionally, we would have to keep the transaction optimization level around
in some context until the request bubbles from the data provider handler to
actually saving the transaction. I don't I hope this won't be too messy, but
since the requests are asynchronous, so far I don't see any way around
it. The only thing that might be less messy in the long term is to provide
a bit more generic structure ("request status") that would so far only
include the optimization level and later might be extended to include
e.g. intermediate data. But on the other hand, I'm not sure I have
thought about passing the data between requests hard enough to design
this properly. Should I?
Any other opinions? Thoughts?
_______________________________________________
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org
To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org
