[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