[OASIS Issue Tracker] Commented: (CAMP-31) State change mechanism is unclear

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/CAMP-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34347#action_34347 ] 

Jacques Durand  commented on CAMP-31:
-------------------------------------

It looks like we have been full circle on this one:
Don't think we can close that one yet: at the very least, some editorial clean-up needed:

Section 6.13  says:
 "Where new_state specifies the new desired value for the application state. This specification defines two such values: "suspend", and "resume," whose semantics are as defined in Section 3"
- But Section 3 does not define these states at all. 
- Also,  "suspend", and "resume" sound more like operations names, not state values.

Also, 1.2 says that a number of operations are possible on a run-time: "•Run, stop, suspend, snapshot, and patch an application". But there is no indication how to "snapshot". Same for "stop".

Also, we say at several places  "an Assembly represents a running [instance of an] application"  (2.2) Does that means that an Assembly doe snot represent a suspended or stopped application? Does the Assembly disappear then when we change from running state to another state?


> State change mechanism is unclear
> ---------------------------------
>
>                 Key: CAMP-31
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-31
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Bug
>          Components: Spec
>            Reporter: Jacques Durand 
>            Assignee: Jacques Durand 
>
> (filed jointly with Tom Rutt)
> In CAMP draft there seems to be a confusion in section 6.11 about the name of a state and the name of the operation leading to that state.
> -----"{"new_state" : "<new-state-value>"} 
> Where, new_state specifies the new desired value for the application state. This specification defines two such values: "suspend", and "resume,"..."-----
> But resume/suspend are operations - not "new states".
> In fact, it seems more natural to control lifecycle (state transitions) with operation names (like in CIMI) rather than by stating the "new state". The latter may appear more RESTful but is rather limited for controlling enterprise apps.
> The specification should clarify the state-changinf mechanism. Using operation names in requests instead of "new state" has some advantages:
> (a)	There may be more than one way to get to a new state from a current state (so using state name is not enough).
> (b)	There might be a need for operations that don't change state. E.g. an op that verifies whether or not a PDP is deployable on a platform even before we try to deploy it.
> Unless we are sure (a) and (b) never apply then we can use "new state" names (in which case 6.11 still need to be fixed). But that needs some investigation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira