| Adrian,
Could we add this issue to today's agenda? I'd like to review the proposal and see what people think.
~ gp
[ http://tools.oasis-open.org/issues/browse/CAMP-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilbert Pilz updated CAMP-31:
-----------------------------
Proposal:
- Add the use of operation names to control state changes. Define a core set of operations for core state transitions. (Of course that does not prevent some platform from automatically transitioning to some core states e.g. at loading time, nor to add new operations leading to a core state). The request could use: {"operation": "suspend"}
- still allow as well for the "declarative" way to change state {"new_state": "suspended"}. This would mean that a platform may have to decide of a default transition path in case more than one exists.
Concrete proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50819/camp-spec-v1.1-issue-31-v1.doc
was:
- Add the use of operation names to control state changes. Define a core set of operations for core state transitions. (Of course that does not prevent some platform from automatically transitioning to some core states e.g. at loading time, nor to add new operations leading to a core state). The request could use: {"operation": "suspend"}
- still allow as well for the "declarative" way to change state {"new_state": "suspended"}. This would mean that a platform may have to decide of a default transition path in case more than one exists.
Now that we have operations that can (presumably) change the state of an Application Component or Platform Component, the simplest thing to do is just reflect the state of that Component in an attribute. The concrete proposal adds a "state" attribute to the ApplicationComponent and PlatformComponent resources. This value is mutable by the Provider but not Consumer mutable. This proposal defines an initial set of state values and allows for extensions to this set.
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|