[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=31822#action_31822 ] 

Tobias Kunze  commented on CAMP-31:
-----------------------------------

    > a Provider want s to extend the CAMP basic state machine by providing different ways to get to the same state [...]

I'm not sure I understand the concern correctly. To me, and as I said above, this is simply a matter of representing these operations (e.g. "different modes of starting/running an application") as individual states. For example, let's assume an implementation offers a "regular" and a "fast" application startup operation (where the latter skips e.g. loading all but the most essential classes). I.e. we'd have now two transitions from "stopped" to "running". A "natural" RESTful extension would then be to add a new state, e.g. "fast start", from which the implementation would transition automatically to "running". Formally, we'd have then two different state transitions: S -> R and S -> F=R (where "F=R" indicates the automatic transition).

Again, all of this seems to me to be a matter of style. If you are used to think in Cartesian, you prefer x and y axes, if Polar, x and w. The systems are equivalent. We just need to avoid mixing them.

    > I also believe at the F2F we saw as legitimate doing extensions that create more than 1 transition between 2 states

Yes, we discussed this as legitimate.

    > a Provider wants to add non-state-changing operations to the basic CAMP state machine (other than GET)

It seems to me that, if this operation does not interact with the lifecycle, we should have not issue. E.g. if I POST a new application name to my Assembly resource, the state would be unaffected. It becomes more difficult in cases where my operation does interact. For instance, my company may prevent me from starting an application until a press release has hit the wire. This would be something that really requires a different state or some extra logic (in my application) that aborts an S->R transition unless a certain condition holds true. If the Platform would provide such a state, i.e. "stopped, not-deployable", this would be a straightforward extension by adding this state as a satellite state to "stopped". I.e. I can move the app into that state and then back to "stopped" when I am ready to launch.


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