[occi-wg] OCCI MC - State Machine Diagram

[Roger Menday]

>>
>> > I am not feeling comfortable with having a state model which
>> > will change on the fly, depending what a resource will
>> > answer.  For one thing, it will make user interfaces and
>> > tools really difficult to design:
>> >
>> >  - should I add a suspend button, even if it works only sometimes?
>> >  - if it worked once, will it work again?
>> >  - what can I do if it does not work?  I want to suspend,
>> >    dammit! ;-)
>>
>> I don't share your pessimism, but then again, I also think we are
>> getting our wires crossed. I think there is a lot of help here from
>> hateoas which does a lot to address your concerns above (??)
>>
>> That was exactly the point of introducing both together - given  
>> that most of the innovation is going to happen server side, clients  
>> should be as dumb as possible. That is, it doesn't matter if a new  
>> state comes along after a client has shipped because it will be  
>> advertised as a potential transition (HATEOAS), perhaps even with  
>> the expected target state.
> I totally agree.
>
> Great. Anyone doesn't agree with the need for [and proposed solution  
> offering] flexibility in the state model?
>
>> The temptation is to assume that infrastructure is a simple problem  
>> with a fixed domain but I can assure you this not the case -  
>> without allowing for such flexibility each implementor will find  
>> themselves having a good chance of running into functions they are  
>> not able to expose via the API, or which the API expects but which  
>> are not present (for example, if "stop" implicitly results in  
>> "destroy" should we offer "stop" at all?).
>
> My point was I wanted to talk about the "states as verbs" model  
> which currently on the wiki ...
>
> So the question is do you ask a "RUNNING" resource to "STOP" by  
> pressing a button in order to get it to the "STOPPED" state or do  
> you update its status from "RUNNING" to "STOPPED". To me the latter  
> is unclean because who are you to say you're going to get to that  
> state immediately, or indeed that you'll even get there at all -  
> updating the status of a "STOPPED" machine to "RUNNING" makes no  
> sense if there's an operating system error that causes the boot to  
> fail for example. I certainly prefer pressing a "START" button,  
> having a transitional "STARTING" state with an accurate progress  
> indicator and eventually reaching a "RUNNING" state. There's some  
> sense in a parametrised "transition-to" function of some sort with  
> an array of potential target states but I still think I prefer the  
> actuator approach that we currently have.

Hi Sam,

My thoughts on both your post and that of Chris too. I hope I'm  
reading your email correctly.

I like posting to a collection, because it does give an obvious holder  
for the state collection, which is then my state history, should i  
need it. I can also publish a membership policy (which changes) of  
what 'types' of new resources can go into a collection. This is useful  
to build the payload. It is also a record of failed transitions.

I don't think this ignores the possibility of a delay or failure in  
state change. After POSTing to the collection, returning a 202, means  
that is has been accepted for processing (if i understand correctly).  
So, there is an (implied) "in-process" sub-state. And the accepted-for- 
processing resource is then a good one to ask why it went wrong, if  
something did go wrong ... (?) That's something I don't see in the  
actuator approach (again I might be missing something) as I don't see  
that it is creating new resources.

Roger

> Sam
>


______________________________________________________________________
                                        
 Fujitsu Laboratories of Europe Limited
 Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
 Registered No. 4153469
 
 This e-mail and any attachments are for the sole use of addressee(s) and
 may contain information which is privileged and confidential. Unauthorised
 use or copying for disclosure is strictly prohibited. The fact that this
 e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield does
 not guarantee that it has not been intercepted or amended nor that it is
 virus-free.