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
>>> 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 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?
> 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?
Ah, yes. If the request returns ERR_STOP_PERIODIC_TASK, the task will be
completely destroyed, otherwise it will reschedule: when EOK, it will
fire the request in last-execution-time + period, otherwise now + period.
>> * 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." should
>> probably say "owned by back end"
> sssd-devel mailing list
sssd-devel mailing list