[occi-wg] OCCI MC - State Machine Diagram

[Alexis Richardson]

Roger

What specific points did you most want feedback on?

a


On Thu, May 14, 2009 at 11:52 AM, Roger Menday
<roger.menday at uk.fujitsu.com> wrote:
>
>
> On 14 May 2009, at 10:59, Alexis Richardson wrote:
>
>> +1 to Sam's "we may need to revisit this point in the name of interop"
>
> I'm not sure if this is *just* an interop thing ...
>
> I thought my suggestions yesterday on how to transition state, error
> reporting, handling 'processing' states, etc ... were reasonable.
>
> Kind of disappointed this morning that I didn't get some feedback from you
> guys ... :(
>
> Roger
>
>>
>> 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.
>