Subject: [lmap] Permanently stopping a schedule manually

From: Ron Stana <[email-masked]>
Date: Tue, 31 May 2016 15:02:23 +0000

LMAP Team,

Can you please provide guidance on how a user should permanently stop a schedule?

Ideal Use Case:

1)      User wants to stop the execution of an existing schedule and has no intention of restarting it.

2)      The Controller instructs the MA to stop the schedule execution

3)      While the MA is stopping the schedule it continues to include the schedule in the response to queries for ietf-lmap-control:lmap-state.   Thus, the schedule continues to be reported as being in the 'running' or 'enabled' state.  Either way the MA continues to show the schedule exists and is taking up resources that could prevent another schedule from executing.   Note that the time to stop a schedule could take minutes if it had hundreds or thousands of connections to remote devices and they have to be torn down using a control protocol.

4)      Once the schedule has stopped the MA then reports this by returning the schedule's state as 'disabled' in queries for ietf-lmap-control:lmap-state.  The last-status can indicate it was stopped manually instead of being in a 'disabled' state because it ran to completion on its own.  Information about failures during clean-up could also be provided such as 'connection to remote device x failed to be torn down properly'.

5)      After the controller retrieves this last state information from the MA it then removes the schedule from the MA, freeing all remaining resources on the MA that were used by the schedule.

6)      The MA no longer reports the schedule when queried for ietf-lmap-control:lmap-state

Currently, LMAP provides:

1)      The ability to remove a schedule (item #5 above).  If used by itself to stop a schedule the information in items #3 and #4 is lost.

2)      A suppression command.  My interpretation of this command is that it is for temporarily stopping a schedule. If this is correct then MA will continue to keep the schedule and thus not free all resources associated with it.  That is not this use case.

3)      Depending on the outcome of this discussion:

https://www.ietf.org/mail-archive/web/lmap/current/msg02524.html

if the ietf-lmap-control:lmap/schedules/schedule/stop object is kept in the LMAP model it could be used to tell the MA to stop the schedule execution (item #2 above).   This use case could then be supported but only if this object is kept and if this is an expected usage of this object.

Please verify the use case is supported and if so, please either confirm it should be accomplished as stated or provide information on how it should be performed.

Regards,
Ron

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 May 2016 19:19:59 +0200

> 2)      The Controller instructs the MA to stop the schedule execution

What exactly do you mean with that? Do you assume the controller
creates

  ietf-lmap-control:/lmap/schedules/schedule[name='foo']/end = 'immediate'

or do you assume something else?
 
> 3)      While the MA is stopping the schedule it continues to include the schedule in the response to queries for ietf-lmap-control:lmap-state.   Thus, the schedule continues to be reported as bein…

If the schedule is 'enabled' and not 'running', then there is nothing
to stop. If you want to prevent a schedule to run in the future, make
sure the start property refers to an event source that does not
trigger anymore. If the schedule is running (which means at least one
action of the schedule is running), then indeed the running actions
might linger around for a while until they terminate.

> 4)      Once the schedule has stopped the MA then reports this by returning the schedule's state as 'disabled' in queries for ietf-lmap-control:lmap-state.  The last-status can indicate it was stop…

In my implementation, 'disabled' is reported only if the
implementation figures out that the start event won't ever happen
anymore in the future. I have to check what my code does if future
starts can happen while 'end' has been set to immediate. This is an
interesting corner case to explore and there is a chance that I kick
of the schedule and try to stop it immediately; perhaps in this case I
should not even attempt to start it. Again, I have to check this case.
On the other hand, it also is quite natural to start and immediately
terminate the schedule in this case since not starting it really
creates a special case in the code logic. (What about a future event
source that in certain contexts may behave as immediate? Special cases
always come with a price tag.)

> 6)      The MA no longer reports the schedule when queried for ietf-lmap-control:lmap-state

yep

> 1)      The ability to remove a schedule (item #5 above).  If used by itself to stop a schedule the information in items #3 and #4 is lost.

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.

> 2)      A suppression command.  My interpretation of this command is that it is for temporarily stopping a schedule. If this is correct then MA will continue to keep the schedule and thus not free…

yep

> if the ietf-lmap-control:lmap/schedules/schedule/stop object is kept in the LMAP model it could be used to tell the MA to stop the schedule execution (item #2 above).   This use case could then be…

The 'stop' in the LMAP YANG model is a choice node and not an
instantiatable leaf node. So you either create an 'end' node or a
'duration' node. It makes sense to me to interpret setting 'end' to
'immediate' as a request to stop a running schedule. As said above, I
have not tested this with my implementation yet.

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

---

From: Ron Stana <[email-masked]>
Date: Tue, 31 May 2016 19:48:05 +0000

Juergen,

Thank you for the prompt response.   I understand and agree with what you state.

Based on your response my conclusion is that ietf-lmap-control:lmap/schedules/schedule/end (thank you for correcting me) can be used for this purpose and if it is not kept due to the other discussion thread that LMAP will provide an alternative mechanism for stopping a schedule since it is a valid use case.

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?  

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.     

Ron

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Tuesday, May 31, 2016 1:20 PM
To: Ron Stana
Cc: [email-masked]
Subject: Re: [lmap] Permanently stopping a schedule manually

> 2)      The Controller instructs the MA to stop the schedule execution

What exactly do you mean with that? Do you assume the controller creates

 
> 3)      While the MA is stopping the schedule it continues to include the schedule in the response to queries for ietf-lmap-control:lmap-state.   Thus, the schedule continues to be reported as bein…

If the schedule is 'enabled' and not 'running', then there is nothing to stop. If you want to prevent a schedule to run in the future, make sure the start property refers to an event source that does not trigger anymore. If the schedule is running (which means at least one action of the schedule is running), then indeed the running actions might linger around for a while until they terminate.

> 4)      Once the schedule has stopped the MA then reports this by returning the schedule's state as 'disabled' in queries for ietf-lmap-control:lmap-state.  The last-status can indicate it was stop…

In my implementation, 'disabled' is reported only if the implementation figures out that the start event won't ever happen anymore in the future. I have to check what my code does if future starts can happen while 'end' has been set to immediate. This is an interesting corner case to explore and there is a chance that I kick of the schedule and try to stop it immediately; perhaps in this case I should not even attempt to start it. Again, I have to check this case.
On the other hand, it also is quite natural to start and immediately terminate the schedule in this case since not starting it really creates a special case in the code logic. (What about a future event source that in certain contexts may behave as immediate? Special cases always come with a price tag.)

yep

> 1)      The ability to remove a schedule (item #5 above).  If used by itself to stop a schedule the information in items #3 and #4 is lost.

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.

yep

> if the ietf-lmap-control:lmap/schedules/schedule/stop object is kept in the LMAP model it could be used to tell the MA to stop the schedule execution (item #2 above).   This use case could then be…

The 'stop' in the LMAP YANG model is a choice node and not an instantiatable leaf node. So you either create an 'end' node or a 'duration' node. It makes sense to me to interpret setting 'end' to 'immediate' as a request to stop a running schedule. As said above, I have not tested this with my implementation yet.

/js