[occi-wg] OCCI MC - State Machine Diagram
Roger Menday
roger.menday at uk.fujitsu.com
Thu May 14 06:17:20 CDT 2009
On 14 May 2009, at 11:55, Alexis Richardson wrote:
> Roger
>
> What specific points did you most want feedback on?
Maybe I am getting actuators wrong ... it could be, I like the Sun
API, and they use actuators. But, actually, actuators don't seem that
great, and they have filtered down into the verb part of the noun-
attribute-verb model. And so, I think it is interesting to explore
other ways of doing it, which address (these overlap)
- async concerns
- error reporting
- offering porential of something more than just pressing a button
(move a few dials then press a button, for ex)
A different perspective is that in the state should be part of the
model, not as a enumerable defined in a registry.
Roger
>
> 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.
>>
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.
More information about the occi-wg
mailing list