[occi-wg] OCCI MC - State Machine Diagram

[Sam Johnston]

On Thu, May 14, 2009 at 2:58 PM, Roger Menday
<roger.menday at uk.fujitsu.com>wrote:

> Sam
>
>
>> 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
>
>
> Status/error fields would be one simple solution to this problem - we
> already have HTTP 20x error codes to indicate that something is indeed
> async.
>
> I think that is a good way.
>
> The thing (that I understand about the actuator) approach, or rather I have
> not seen documented anywhere, was that POSTing to an actuator URI doesn't
> seem to create a resource anywhere. So, we can't do that right now.
>
> OK, maybe that is something for OCCI 2.0, but why not do it now ?
>

You need a resource to find an actuator so just poll the same resource for
status updates - that is, we can have a verbose text status field in
addition to the enum. To clarify:

   - Actuators that act immediately will return 200 OK.
   - Those that don't will return 202 Accepted.
   - Those that create a resource will return 201 Created with a Location:
   header pointing at the newly created resource (where that could presumably
   be a feed of resources if you asked for multiple instances).

Ok by you?


> An eventlog extension is another.
>
>
>> - error reporting
>
>
> As above.
>
>
>> - offering porential of something more than just pressing a button (move a
>> few dials then press a button, for ex)
>>
>
> This is likely to be an absolute requirement - I don't want to have to
> press the start button 50 times to get 50 instances so there will need to be
> some way to create-en-masse for a start (probably with the flexibility of
> ranges ala amazon). I may also need to specify cold start vs warm start
> (e.g. with or without state). I've not really even started thinking about
> this yet, beyond knowing that there are a few potential solutions.
>
> So, actuators don't seem to cover this (?)
>
> Modeling state discovery *and* request as part of a model does seems to be
> a good alternative.
>

It just means you need to pass parameters to the actuator via a GET or POST
request (GET comes to mind first but POST works with more/larger
parameters)... these exceptional cases can go in the registry... for start
it might be 'min-instances' and 'max-instances' for example.


>
>
>
>> A different perspective is that in the state should be part of the model,
>> not as a enumerable defined in a registry.
>>
>
> Sure, this is the more formal approach but it's also more rigid/brittle. As
> we can't hope to predict every state that will ever exist, least of all in a
> fashion that is understandable/acceptable to everyone, we need to be
> flexible.
>
> Yes, but, the people need to conform to some extent. That's why we are
> having this JSON vs ATOM discussion, right ? They also need to conform to a
> basic state model, and then allow states to be specialized if necessary.
> Don't you actually get this if you have  state modeled as part of a class
> model; a simple one that everyone can live with - rather like the one in the
> OGF Reference Model - together with sub-classing for more specialist cases
> ?
>

I'm still having trouble making this reconcile - force people into your
model and you are sure to break something for someone, unless you make it so
high level as to be meaningless. sub-classing and categories have the same
result - multiple actuators bundled under one heading... if I want to stop
the device do I press "shutdown", "halt", "acpioff", "poweroff" or just
choose one at random? Better bet is to let implementors make sensible
decisions like "try shutdown, wait a minute then do acpioff followed by
poweroff if we're still not where we want to be"... think of the "Force
Quit" and "End Task" options in windows.

States that don't fit are things like "archiving", "restoring", "backing
up", "cloning", "transferring", "transforming"... who's to say there's not
going to be a "teleporting" state one of these days?

It won't be anarchy and even if it were we'd just add some constraints... in
any case we won't know until we suck it and see.


> So, generically processed by everything at some level. That takes care of
> brittleness, right ?
>
> Roger
>
> ps. Actually, I would've thought that having the state of something as a
> stream of updates inside an feed would appeal to a "atom/atompp for occi"
> proponent ?
>

Providing a link to a feed of syslog/eventlog style entries is something
that I had envisaged, and doing something similar for state changes/requests
(even as a subset of same) does sounds sensible.

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