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
>>I wrote a design document:
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
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
No, that was just future extensibility.
> * The design page says that "cancelling request if current
> 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?
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?
>One grammar nitpick - " The periodic tasks will be held by back end."
>probably say "owned by back end"
sssd-devel mailing list