On Thu, Apr 25, 2013 at 11:18:28AM +0200, Pavel Březina wrote:
I've been assigned ticket https://fedorahosted.org/sssd/ticket/1713: [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 work.
I wrote a design document: https://fedorahosted.org/sssd/wiki/DesignDocs/PeriodicTasks
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"