[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