[SSSD] Design Discussion: Periodic task API

Jakub Hrozek jhrozek at redhat.com
Mon Apr 29 09:35:31 UTC 2013


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?

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



More information about the sssd-devel mailing list