[occi-wg] OCCI MC - State Machine Diagram

[Alexis Richardson]

+1 to Sam's "we may need to revisit this point in the name of interop"

At this stage we are shooting for a draft.  The draft will let people
implement prototypes which will let us debug interop and refine the
model.


On Thu, May 14, 2009 at 10:55 AM, Sam Johnston <samj at samj.net> wrote:
> On Thu, May 14, 2009 at 10:23 AM, Andre Merzky <andre at merzky.net> wrote:
>>
>> Quoting [Sam Johnston] (May 13 2009):
>> >
>> >>     Yes, me, I don't think HATEOAS should be applied in this
>> >>     context.   But I realise/accept that I maybe the only one
>> >>     with that opinion - thats ok.  So I'll say it here one last
>> >>     time, for the record, and then will shut up: "a static
>> >>     simple state model allows for very simple clients.
>> >>     Extensions can be defined via substates, or additional
>> >>     transitions."
>> >
>> >    I would counterargue that HATEOAS allows for even simpler clients
>> >    because they don't have to worry about hardwiring even a simple state
>> >    model. Using HTTP we can even feed them plain $LANG descriptions of
>> >    what the transitions and targets are - it doesn't get any easier than
>> >    that and you don't have to worry about updating clients to implement
>> >    new goodies.
>>
>> I don't see that.  If  I want to write a client tool which
>> starts a resource, I want to make sure the resource is in
>> RUNNING state when the client reports success.  But if that
>> client (a) has to infer the available states from a
>> registry, it cannot posisbly know which state has the
>> semantic meaning of RUNNING attached.  Further (b), if the
>> client only sees those state transitions it is allowed in
>> its current state, how does it know what transition path to
>> take to reach that target state?  Is it (I am making those
>> up obviously):
>>
>>  INITIAL -> create() -> CREATED -> elevate() -> ELEVATED () -> run() ->
>>  RUNNING
>>
>> or
>>
>>  INITIAL -> create() -> CREATED -> init() -> INITIALIZED -> run() ->
>> RUNNING
>>
>> Or should the tool simply fail because it cannot see a run()
>> transition in its INITIAL state?
>
> The client must at least know how to create a resource and when it has done
> so successfully a "start" actuator will appear, perhaps with a target state
> of "running" (TBD). In that case it knows that if it pulls the "start"
> handle eventually the resource should end up "running". Otherwise it could
> know (from the registry) that "start" is the right button to push, but
> that's starting to break HATEOAS principles. We have options - it's just a
> matter of finding the right one.
>
>>
>> I think HATEOAS works pretty well if a human is in the loop
>> who can parse the available transition description, and
>> deduce a semantic meaning.  I don't think it makes for
>> simple tooling, really.
>
> I agree that humans are better at this stuff than computers but I'm
> unconvinced this translates to complex tooling.
>
>>
>> Then again, I may misunderstand the proposed usage of
>> HATEOAS in OCCI.  So, can you help me out: what mechanism
>> will avoid the confusion from the example above, if a vendor
>> can provide init() and elevate() transitions on the fly,
>> with no predefined semantics attached?  How would my tool
>> deduce the transition path it needs to enact?
>
> The semantics for common functions will be in the registry. It's ones that
> are uncommon and impossible to predict like "translate" and "migrate" that
> we're catering for here, and generally there will need to be some kind of
> client side support for these.
>
> As I said below, "we may need to revisit this point in the name of interop",
> and I suggested categories as one possible solution (e.g. a "starting" vs a
> "stopping" transition)... parametrised transition calls are another... for
> example, how do I tell something to start *without* saved state if saved
> state is present (ala cold start vs resume)?
>
> Sam
>
>>
>> >    I don't think anyone knows every possible thing that users are going
>> > to
>> >    want to do with the API (I certainly don't have the confidence to say
>> > I
>> >    do anyway) but we may need to revisit this point in the name of
>> >    interop... Atom categories would be one way to achieve this (e.g.
>> > "Cold
>> >    Reboot" and "Warm Reboot" might go in the "restart" category).
>> >    Sam
>> >
>> > References
>> >
>> >    1. mailto:andre at merzky.net
>>
>>
>>
>> --
>> Nothing is ever easy.
>
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>