[occi-wg] OCCI MC - State Machine Diagram

[Andre Merzky]

Hi Sam, 

I am not sure I understand how you expect extensions to the
state model to work.  

For example, assume that I have a client which implements
the core specification only, thus only knows the STOPPED,
ACTIVE and SUSPENDED states (your original figure).  What is
that client supposed to do if the backend reports an PAUSED
state?

It is a standards compliant client, so I would expect it to
work with a standards compliant backend.  However, the
extension registry as it exists right now would break
backward compatibility.

One solution would be to register new states as substates of
existing states.  PAUSED for example could be registered as
substate for SUSPENDED.  What is the difference?  Well, the
state reported by the backend would be SUSPENDED, which the
client understands.  The client would also know that the
resume() operation is valid for that state.  Other clients
which implement the extension would obtain the state
SUSPENDED and the state_detail PAUSED, and learn that way
that the client does not accept new requests.  Voila:
backward compatibility.

Of course, that model poses limitations: it does not allow
extensions which allow transitions which are not present
within the top level state diagram.  e.g., no extension
could implement a direct transition from PAUSED to STOPPED,
as this is not in your original state diagram.  I, however,
do not consider that to be a bug, but a feature: it
guarantees that the top level state model is preserved even
if extensions are present.



BTW, I agree with Krishna's point that ENTRY and EXIT
points are useful.

Cheers, Andre


Quoting [Sam Johnston] (Apr 18 2009):
> Date: Sat, 18 Apr 2009 19:20:37 +0200
> From: Sam Johnston <samj at samj.net>
> To: "Krishna Sankar (ksankar)" <ksankar at cisco.com>
> Cc: occi-wg at ogf.org
> Subject: Re: [occi-wg] OCCI MC - State Machine Diagram
> 
>    I've added both to the registry:
>    [1]http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Regis
>    tries
>    Sam
> 
>    On Sat, Apr 18, 2009 at 6:13 PM, Krishna Sankar (ksankar)
>    <[2]ksankar at cisco.com> wrote:
> 
>    Sam,
> 
>                    Just for clarity, resources shouldnt enter the state
>    matrix at any point. For example they cannot enter the matrix in
>    Stopping stage or leave while in Active/Running state. That is why the
>    entry and exit points are important. But, of course, we will discuss
>    these in detail as we progress.
> 
>                    Yep, a Pause state is required. Good catch.
> 
>    Cheers
> 
>    <k/>
> 
> 
>    From: Sam Johnston [mailto:[3]samj at samj.net]
>    Sent: Saturday, April 18, 2009 9:04 AM
>    To: Krishna Sankar (ksankar)
>    Cc: Chris Webb; [4]occi-wg at ogf.org
>    Subject: Re: [occi-wg] OCCI MC - State Machine Diagram
> 
> 
>    Hi Krishna,
>    Thanks for the feedback.
> 
>    On Sat, Apr 18, 2009 at 5:22 PM, Krishna Sankar (ksankar)
>    <[5]ksankar at cisco.com> wrote:
> 
> 
>    a)      The diagram needs a entry and exit point circles (actually
>    concentric circles)
> 
>    Resources can enter or leave the matrix at any point (e.g. you can
>    import or migrate a suspended workload) so I think adding this, while
>    technically correct, might impair readability (as it does in the DMTF
>    diagram). The formal specification might want to include a formal state
>    diagram however.
> 
>    b)      The Stopping and Starting states are important. For example if
>    the state is Starting, clients could retry; schedulers could add the VM
>    in their pool et al. Stopping state will mean that the system is not
>    accepting service requests anymore. It might have to stay in this state
>    until all pending requests are completed.
> 
>    Sure, but it's really up to the provider as to whether they want to
>    implement these. Some workloads (e.g. slices) start atomically so the
>    transition doesn't make sense. We'll cater for the need but I'm a big
>    fan of giving implementors maximum flexibility.
> 
>    c)       There is another state Aborting dont know if we want to add
>    this.
> 
>    Interesting idea - perhaps we'll include it in the registry as one of
>    those "optional" states. Another interesting one is "paused", where no
>    new requests will be accepted but all those in progress will be
>    finished - a load balancer shouldn't send any new requests but it
>    shouldn't terminate any existing ones either.
> 
>    d)      The stopped state, while not important during run time, will be
>    useful for account keeping, auditing et al. For example a log entry
>    with Stopped state with a timestamp
> 
>    Perhaps, but simpler systems might operate without billing or have a
>    simple meter based approach. If the infrastructure doesn't already
>    maintain information about stopped resources then we don't want to
>    force them to in order to implement the API.
> 
>    e)      Remember, monitoring and billing is an important plane for
>    Clouds and so we should also have states that are relevant from that
>    perspective
> 
>    Agreed. I don't think we should get too deep into this, but we should
>    bear in mind that the ability to see/compare costs in the clients
>    delivers huge value. I've included some simple metering examples to get
>    the creative juices flowing.
>    Sam
> 
>    Cheers
> 
>    <k/>
> 
> 
>    From: [6]occi-wg-bounces at ogf.org [mailto:[7]occi-wg-bounces at ogf.org] On
>    Behalf Of Sam Johnston
>    Sent: Saturday, April 18, 2009 6:14 AM
>    To: Chris Webb
>    Cc: [8]occi-wg at ogf.org
>    Subject: Re: [occi-wg] OCCI MC - State Machine Diagram
> 
> 
>    On Sat, Apr 18, 2009 at 1:43 PM, Chris Webb
>    <[9]chris.webb at elastichosts.com> wrote:
> 
>    Sam Johnston <[10]samj at samj.net> writes:
>    > I have created a diagram (attached) of what I think the absolute
>    minimum
>    > core states need to be... essentially boiling them down to "STOPPED"
>    and
>    > "ACTIVE" with "START" and "STOP" being the only requisite actuators.
>    > Transitional "STOPPING" and "STARTING" states are optional.
> 
>      +1
>      I strongly agree with simplifying things in this way. Good stuff!
> 
>    I subsequently realised that in fact infrastructure like Amazon, Mosso
>    and ElasticHosts don't actually have a "stopped" state - "stop" for
>    these guys is more like "destroy".
>    It then occurred to me that there was no point making "stopped"
>    optional as if you don't need to start/stop/restart machines then you
>    just don't implement the machine control extension. It's far easier to
>    create (HTTP PUT) and then destroy (HTTP DELETE) a server than what it
>    is to parse the response to fire an actuator.
>    So basically the machine control extension becomes optional (but
>    possibly still interesting to indicate transitional states like
>    "starting" and "stopping" as Chris pointed out privately).
>    Sam
> 
> References
> 
>    1. http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Registries
>    2. mailto:ksankar at cisco.com
>    3. mailto:samj at samj.net
>    4. mailto:occi-wg at ogf.org
>    5. mailto:ksankar at cisco.com
>    6. mailto:occi-wg-bounces at ogf.org
>    7. mailto:occi-wg-bounces at ogf.org
>    8. mailto:occi-wg at ogf.org
>    9. mailto:chris.webb at elastichosts.com
>   10. mailto:samj at samj.net

> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg




-- 
Nothing is ever easy.