[SSSD] Design Discussion: Periodic task API

Pavel Březina pbrezina at redhat.com
Mon Apr 29 09:07:09 UTC 2013


On 04/29/2013 10:00 AM, Jakub Hrozek wrote:
> 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
>

Hi,
I didn't expect any major issue with the design so I already wrote the 
code on Friday. You can take a look at nss-periodic branch in my repo.

> 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

Do you have any particular use case? I didn't thought of any. But I 
guess it won't hurt to add it. If anything, it will make easier to 
ensure that it is freed when private data (like sdap_id_ctx) is freed.

>   * 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?

Yes.

  Is the rescheduling configurable?

How would you like to configure it?

>   * What about online/offline callbacks? Some tasks should be re-enabled
>     when the BE goes online or cancelled when the BE is offline

If this is needed then you should create the task in online callback and 
destroy it in offline callback.

> 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