[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=32252#action_32252 ]
Adrian Otto commented on CAMP-31:
---------------------------------
> We could do something like support a 'fork' operation on an Application resource. Forking an Application resource would
> create another instance of that resource, subject to the whatever parameterization we decide to resolve CAMP-30 with.
For that to work, I imagine that each such resource would need to carry the information we would normally store in the template. Specifically, the resource probably has information about what specific instances of components and services it is connected to. Information about requirements would normally be dropped at this point because they have been satisfied. A template cares about requirements to map them to components with matching capabilities. If we merged the two concepts, the resulting resource would be something that is the intersection of all information from both an Assembly Template and an Assembly. That might end up being a lot more complicated than it needs to be when instead it could just link to a template resource that has all the requirements information in it.
> It just feels to me like the Assembly Template/Assembly split is part-and-parcel of our previous decision to use a
> state-oriented style. For example, if invoking the 'stop' operation on an Assembly instance causes that instance to go away
> (because there is no longer a running application for it to represent), why not just use HTTP DELETE to do the same thing?
That detail was probably an oversight. We should be using DELETE on an Assembly to stop an application. We should be offering "suspend" and "resume" as operations, but not "stop". We should open an issue to adjust 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]