On Thu, Apr 25, 2013 at 11:18:28AM +0200, Pavel Březina wrote:
I've been assigned ticket
[RFE] Add a task to the SSSD to periodically refresh cached entries
I have recently created a ticket (#1891) to unite API for managing
periodic tasks. We already quite a periodic task (enumeration, sudo,
dyndns, #1713) when each of them implements custom API.
None of these are generic enough to be used for #1713 so I will have
to create a new one. I'm not suggesting to refactor the old code
now, that will be done when #1891 is scheduled.
But I think it is a good idea to create the generic one now instead
of a new feature-specific. It will be basically the same amount of
I wrote a design document:
I have a couple of questions:
* The create functions has no memory context parameter. I was thinking
that in some cases you might want to allocate the structure on
something else than be_ctx and more importantly, cancel the task when
the context in question goes away
* The design page says that "cancelling request if current tevent
request bound to this task takes more than timeout seconds" is a job
of the be_periodic_task_create(). Does it also reschedule the job in
that case? Is the rescheduling configurable?
* What about online/offline callbacks? Some tasks should be re-enabled
when the BE goes online or cancelled when the BE is offline
One grammar nitpick - " The periodic tasks will be held by back end." should
probably say "owned by back end"