[occi-wg] OCCI MC - State Machine Diagram

[Sam Johnston]

On Wed, May 13, 2009 at 4:20 PM, Roger Menday
<roger.menday at uk.fujitsu.com>wrote:

>
> On 13 May 2009, at 15:13, Sam Johnston wrote:
>
> On Wed, May 13, 2009 at 3:40 PM, Roger Menday <roger.menday at uk.fujitsu.com
> > wrote:
>
>> > 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.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090513/e1259670/attachment.html