OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

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

The discussion at last week's meeting did not reach a clear decision point. We agreed that mixing styles of changing state values was not good. For example, using operations to change values and also allowing put/patch to change values was not good. Operations are in the spec now, and can be used to change values. They will definitely need to change the state values. That means we should prohibit attribute updates if we want to limit to one approach. 

We discussed whether we should have state names for values that our spec does not offer any way to enter. I argued that having a reasonably complete table of state values could be valuable for interoperability, even if we don't define precise semantics for each. It's intractable to solve for all possible semantics, so approaching that in a v.next after we observe some actual implementations makes more sense.

I also don't completely fathom the difference between state and status, so I don't have an opinion about what to call the standard attribute that indicates what state the resource is in.

I'm not sure if we have opposing viewpoints to consider, but I think that's where we landed.

> 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

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]