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=34772#action_34772 ] 

Alex Heneveld commented on CAMP-31:
-----------------------------------

Some specific and I think vital objections to the proposal v1:

* What use for interoperability is a string for state if it is extensible?  A state gets added and clients will not know what it means.

* What state is something in if it is starting up or stopping?

* What state is something in if it stops because it was told to stop after running.  In such case I would say it "is functioning as expected" (it is expected to be stopped), but also it has "stopped functioning", and it has "completed its functioning".  The current language suggests it should have _three_ states simultaneously.

* What state is something in if it has been stopped after encountering an error.  The current language -- "has encountered some sort of error" -- suggests that the state should be both error and and stopped (as well as potentially completed and running, as per previous point!).

* These states do not really make sense to me for an *Application* Component, which is just a bit of user-supplied content.  The state makes sense on PC's where the AC is deployed, but confusing with respect to static content.  Consider a WAR deployed to 2 app-servers, one of which is running and one of which is stopped (or even a third which is in error) -- is the state COMPLETED if it has been transferred, or RUNNING because it is running on at least one.

* I would prefer to have the `state` attribute optional if we have it at all.

In my experience this is a difficult problem to solve well and so I suggest we not attempt to do so at this time.  If we are going to make anything normative I would suggest an optional boolean attribute of the form "serviceRunningHealthily" -- because that is fairly well understood and solves what I think is the primary use case of a caller wanting to know is it running healthily or not -- distinguishing failure from planned stoppage is much harder.

We are incidentally no longer addressing the original issue which concerns a canonical set of *operations*, which is valuable but is similarly difficult.  While a canonical set of operations and states are desirable I believe they can wait until v.next when the spec has been used and users have evolved these (e.g. in the space of characteristics and extensions).

In short I believe the only critical action to resolve this issue for the moment is the removal of section on "Suspending and Resuming an Application".

Also, in general I suggest we give use cases for features such as this.  And Gil, I feel bad I am dinging it after your detailed work to make the document just right:  we can always discuss it in the issue first!


> 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]