[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=32265#action_32265 ] 

Adrian Otto commented on CAMP-31:
---------------------------------

On 29/Jan/13 11:45 PM Tobias Kunze wrote:
> I don't think it is prudent to identify "instantiation" with "running". An Assembly can very well exist (be instantiated 
> from a template) and be in STOPPED state, no? Instantiation should merely involve concretization of parameters.

I smiled when I read this, because I made the very same argument about cloud servers when we were building that API for our compute service. The argument fell apart when thinking about what it would mean practically in practice. It turns out that in order to have an application in STOPPED state, all the underlying components would still need to remain provisioned, taking up capacity in the system. The service provider will end up still billing for that capacity, probably at the same rate as if the application were running. Furthermore, if it's relatively quick to get from a template to an assembly, there is little value in having a stopped state.

This means the customer has no incentive to use the stopped state, yet does have an incentive to DELETE the application, free the resources, and benefit from reduced costs.

We should probably have an ERROR state where an assembly does exist, but some critical component has malfunctioned.

I will not argue against the value of a SUSPENDED state, where running resources may be hibernated to a less expensive use of capacity. However, I would challenge us to rethink the value of STOPPED before requiring implementation of that.

> 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