[occi-wg] OCCI MC - State Machine Diagram

[Alexis Richardson]

Roger

On Thu, May 14, 2009 at 1:07 PM, Roger Menday
<roger.menday at uk.fujitsu.com> wrote:
>
> I'm interested in learning/participating/influencing - why I was hopeful for
> a reply.

You are extremely welcome to influence and participate - it is vital.

I'm hoping that you'll get some feedback once the US wakes up.

Please keep up the commentary, it does help even if people don't reply.

alexis











>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>
>>
>
>>
>> Roger Menday (PhD)
>> <roger.menday at uk.fujitsu.com>
>>
>> Senior Researcher, Fujitsu Laboratories of Europe Limited
>> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
>> Tel: +44 (0) 208 606 4534
>>
>>
>> ______________________________________________________________________
>>                                      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.
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>
> Roger Menday (PhD)
> <roger.menday at uk.fujitsu.com>
> Senior Researcher, Fujitsu Laboratories of Europe Limited
> Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE, U.K.
> Tel: +44 (0) 208 606 4534
> ______________________________________________________________________
>
> 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.
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
>