Subject: Re: [lmap] Permanently stopping a schedule manually

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 8 Jun 2016 12:47:18 +0200

On Tue, May 31, 2016 at 07:48:05PM +0000, Ron Stana wrote:
 
> I have one follow-up question.  You wrote:
> 
> [JS] I think my implementation does the following: If you remove the schedule from the config tree, then the scheduled actions still exists in the state tree.
> 
> After the schedule has been removed, for example: 
> HTTP DELETE /restconf/data/ietf-lmap-control:/lmap/schedules/schedule[name='foo']
> then if your MA continues to report the schedule in response to queries for ietf-lmap-control:lmap-state, what causes your MA to stop returning that schedule?  

It will be removed from the state tree once it is not running anymore.

> If status is expected to be returned for schedules after they have been removed -say for x amount of time after removal or until y amount of new schedules have been accepted - I think this should be specified in the LMAP documentation.

The only interesting corner case is if you remove a schedule that is
currently running. There are differnet ways to handle this:

a) Terminate the running schedule and afterwards remove the schedule
   from the config tree.

b) Remove the schedule from the config tree, delay the removal of the
   running schedule from the state tree until it has terminated.

c) Refuse any attempts to remove the schedule from the config tree
   until the schedule is not running anymore.

d) Any other behaviour (core dump and reboot ;-)

Looking at my code, loading a new config cause the whole eventloop to
quit and to restart but I am keeping the daemon state. So I think my
idea was to implement b) but I am not sure yet whether I really
managed - I might end up doing d) in some way.

Looking at some of the discussions going on in the NETMOD WG, this can
also be seens as a case where intended configuration may temporarily
differ from the applied configuration, i.e., if you remove a schedule
from the intended configuration, then this is accepted but no taking
effect in the applied configuration until any running schedules have
completed.

The issue with b) is that it opens the floor for temporary
inconsistencies, e.g., you replace a running schedule with a different
one using the name and then it appears as if the new one is running
while what is running is actually an older one.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>