[SSSD] Design Discussion: Periodic task API

Jakub Hrozek jhrozek at redhat.com
Mon Apr 29 08:00:18 UTC 2013


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"



More information about the sssd-devel mailing list