[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (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=32511#action_32511 ]
Jacques Durand edited comment on CAMP-31 at 2/20/13 2:23 PM:
--------------------------------------------------------------
The original concern behind this issue is more about the limitations / risks of the "declarative" state change ("new_state"), primarily for run-time resources (assemblies). Not for states that don't involve run-times (e.g. "uploaded" "deployed"). I think the operation URI approach suggested by Adrian (attribute "suspendUri" : "..." ) would address it, and allows nicely for extensibility.
I would not expect this approach to apply to ALL operations leading to a state change (e.g. to UPLOADED, DEPLOYED...) : because different [application] resources are involved at different states, we can cleanly restrict the operation URI approach to some resources (here Assemblies) meaning here, to "run-time" entities.
In fact I think we may need to clean-up our notion of "state" and state diagram in another issue ( what we call "application" sometimes is just represented as a template resource, sometime as a run-time entity, sometimes as several run-time entities) . So in practice, an application can be at the same time DEPLOYED and INSTANTIATED (or RUNNING, or SUSPENDED, or all of the above ! In fact, since an application can have several instances, some SUSPENDED some RUNNING etc, we cannot really talk abstractly as if all this is a single application. This is not well rendered by our current state diagram.
was (Author: jdurand2):
The original concern behind this issue is more about the limitations / risks of the "declarative" state change (new-state), for run-time resources (assemblies). I think the operation URI approach suggested by Adrian (attribute "suspendUri" : "..." ) would address it, and allow for extensibility.
I would not expect this approach to apply to ALL operations leading to a state change (e.g. to UPLOADED, DEPLOYED...) as I believe we can/should more cleanly separate the notion of "run-time" (states of Assemblies) from the general notion of "application" that we seem to use e.g. when we say the application is DEPLOYED.
In fact I think we may need to clean-up our notion of "state" and state diagram in another issue ( what we call "application" sometimes is just represented as a template state, sometime as a run-time entity, sometimes as several run-time entities) . So in practice, an application can be at the same time DEPLOYED and INSTANTIATED (or RUNNING, or SUSPENDED, or all of the above ! In fact, since an application can have several instances, some SUSPENDED some RUNNING etc, we cannot really talk abstractly as if all this is a single application. This is not well rendered by our current state diagram.
> 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]