[occi-wg] OCCI MC - State Machine Diagram

Krishna Sankar (ksankar) ksankar at cisco.com
Sat Apr 18 12:34:56 CDT 2009

Good point. I think we will need conformance levels (say 1,2 and 3) so
that we can introspect and infer what an implementation will support.
Agreed, at the instance level, we do need to be deterministic.


|-----Original Message-----
|From: Andre Merzky [mailto:andremerzky at gmail.com] On Behalf Of Andre
|Sent: Saturday, April 18, 2009 10:30 AM
|To: Sam Johnston
|Cc: Krishna Sankar (ksankar); occi-wg at ogf.org
|Subject: Re: [occi-wg] OCCI MC - State Machine Diagram
|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
|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-
|>    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
|>    matrix at any point. For example they cannot enter the matrix in
|>    Stopping stage or leave while in Active/Running state. That is why
|>    entry and exit points are important. But, of course, we will
|>    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,
|>    technically correct, might impair readability (as it does in the
|>    diagram). The formal specification might want to include a formal
|>    diagram however.
|>    b)      The Stopping and Starting states are important. For
|>    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
|>    accepting service requests anymore. It might have to stay in this
|>    until all pending requests are completed.
|>    Sure, but it's really up to the provider as to whether they want
|>    implement these. Some workloads (e.g. slices) start atomically so
|>    transition doesn't make sense. We'll cater for the need but I'm a
|>    fan of giving implementors maximum flexibility.
|>    c)       There is another state Aborting dont know if we want to
|>    this.
|>    Interesting idea - perhaps we'll include it in the registry as one
|>    those "optional" states. Another interesting one is "paused",
|>    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
|>    with Stopped state with a timestamp
|>    Perhaps, but simpler systems might operate without billing or have
|>    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
|>    perspective
|>    Agreed. I don't think we should get too deep into this, but we
|>    bear in mind that the ability to see/compare costs in the clients
|>    delivers huge value. I've included some simple metering examples
|>    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
|>    and
|>    > "ACTIVE" with "START" and "STOP" being the only requisite
|>    > Transitional "STOPPING" and "STARTING" states are optional.
|>      +1
|>      I strongly agree with simplifying things in this way. Good
|>    I subsequently realised that in fact infrastructure like Amazon,
|>    and ElasticHosts don't actually have a "stopped" state - "stop"
|>    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
|>    just don't implement the machine control extension. It's far
|>    create (HTTP PUT) and then destroy (HTTP DELETE) a server than
|>    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-
|>    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.

More information about the occi-wg mailing list