[SSSD] Design Discussion: Periodic task API

Pavel Březina pbrezina at redhat.com
Mon Apr 29 18:47:00 UTC 2013


On 04/29/2013 11:35 AM, Jakub Hrozek wrote:
> On Mon, Apr 29, 2013 at 11:07:09AM +0200, Pavel Březina wrote:
>> 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.
>>
>
> Yeah, sorry, my fault for not responding sooner.
>
>>> 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.
>>
>
> No, that was just future extensibility.
>
>>>   * 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?
>
> I was thinking that in some cases you might not want to reschedule at
> all. If the task fails, it's failed. But I guess this could be handled
> in the task itself by freeing the data structure?
>
>>
>>>   * 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.
>
> OK, can you add that bit to the design page?

I will amend my answer - if we need it, we will implement it as a part 
of be_periodic_task.

Task may successfully open connection to database, turning SSSD back 
online. AFAIK there is currently no use case for disabling the task when 
offline.

>
>>
>>> One grammar nitpick - " The periodic tasks will be held by back end." should
>>> probably say "owned by back end"
>>
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
>




More information about the sssd-devel mailing list