[SSSD] Design Discussion: Periodic task API

Simo Sorce simo at redhat.com
Mon Apr 29 18:12:47 UTC 2013


On Mon, 2013-04-29 at 20:05 +0200, Pavel Březina wrote:
> On 04/29/2013 07:52 PM, Simo Sorce wrote:
> > On Mon, 2013-04-29 at 11:54 +0200, Pavel Březina wrote:
> >>
> >> 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.
> >>
> > Wouldn't it be simpler to simply stop on any error, and reschedule only
> > when EOK is returned ?
> > This way the task can bubble up the error all the wya w/o having to mask
> > it to a ERR_STOP_PERIODIC_TASK error at the very end.
> 
> No, you want to terminate the periodic task only on fatal error which 
> you can't recover from. E.g. you want to reschedule the task when you 
> can't connect to LDAP, but terminate it if LDAP server doesn't support 
> some extension.
> 
> If you return ERR_STOP_PERIODIC_TASK, the task will not be rescheduled. 
> It will be rescheduled on any other error code and logged as appropriate.

I guess the point here is what you want to do by default.
In either case you need to check and remap error codes before returning.

If you define ERR_STOP_PERIODIC_TASK, then you want a continue by
default, let's stop only on white listed errors.

If there is a new 'fatal' error you do not catch in whatever function
normally converts to ERR_STOP_PERIODIC_TASK. Then the task will be
rescheduled.

The other point is that with ERR_STOP_PERIODIC_TASK, you also have to
log where you map because it won't bubble up.

I can see the advantages as well though, so I do not have a strong
preference at this point, carry on :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list