[Nsi-wg] Issue 48 in ogf-nsi-project: Addition of a Failed state into the state machine.

[ogf-nsi-project at googlecode.com]

Status: Accepted
Owner: jmacau... at gmail.com
Labels: Type-Defect Priority-Medium FoundInVersion-1.Rio FixedInVersion-1.1

New issue 48 by jmacau... at gmail.com: Addition of a Failed state into the  
state machine.
http://code.google.com/p/ogf-nsi-project/issues/detail?id=48

Description of Issue:
There is no way within the existing NSI state machine to determine if a  
reservation in the "Terminated" state reached that state through a  
successful execution or through a failure.

Discussion of Issue:
For example, a reservation is modelled by a state machine once a reserve.rq  
is sent and the state machine transitions from the "Initial" to  
the "Reserving" state.  If the reserve.rq fails the existing state machine  
transitions into "Cleaning" and then to a final rest state  
of "Terminated".  Likewise, a successfully executed schedule reaches the  
final rest state of "Terminated".  An observer using the query operation  
would not be able to distinguish the failed schedule from the successful  
schedule after the fact.  It can be even more confusing in that one  
schedule may have failed do to a second schedule, but there is no way to  
tell which after they have completed.

There are two possible solutions:

1. Add a new "Failed" state to the state machine.

2. Add an informational field to the state machine / reservation record  
that tracks the reason for transition into the "Terminated" state.  We  
could model a successful schedule that reached endTime.  A manual  
terminate.  A forcedEnd received from a child or local NRM.  A reservation  
failure (could store the ServiceException).

I do not believe the argument that this is an OAM issue and needs to be  
solved separately is valid in this case.  We need additional information.

Resolution of Issue:

I would recommend option #2.