[occi-wg] OCCI MC - State Machine Diagram

[Krishna Sankar (ksankar)]

Excellent. Agreed. Am a fan of orthogonal extensibility as well. 

 

In which case, let us make the supported states meta-discoverable via an
appropriate policy plane interface. Of course, just discovering will not
solve the problems - one has to figure out the semantics - how to use
the discovered states effectively.

 

BTW, have we started elaborating the canonical model of the different
planes - data, control, management, policy and monitoring/billing ? Or
more precisely is there a placeholder ? I will look around the Wiki - I
assume that is the focal point of our efforts.

 

Cheers

<k/> 

 

From: Sam Johnston [mailto:samj at samj.net] 
Sent: Saturday, April 18, 2009 10:46 AM
To: Krishna Sankar (ksankar)
Cc: Andre Merzky; occi-wg at ogf.org
Subject: Re: [occi-wg] OCCI MC - State Machine Diagram

 

Hi,

I'm really quite sensitive about prematurely throwing a "wet blanket"
over innovation (it is, after all, fairly early to be talking about
standards). That's one of the main reasons for keeping the state engine
on the server side and exposing possible transitions via links:

    <atom:link title="Start"
href="http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/state/star
t" rel="http://purl.org/occi/state#start"/>




    <atom:link title="Stop"
href="http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/state/stop
" rel="http://purl.org/occi/state#stop"/>




    <atom:link title="Restart"
href="http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/state/rest
art" rel="http://purl.org/occi/state#restart"/>




    <atom:link title="Suspend"
href="http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/state/susp
end" rel="http://purl.org/occi/state#suspend"/>





We can't presume to know what weird and wonderful things people will
want to do in the future so the registry is more for the server side
implementors (to encourage them to use existing terms rather than coming
up with their own).

And before you ask, the "title" field is UI friendly and easily
localised using content negotiation (so you can have a "Vaporize"
transition over there which will appear as "Vaporise" over here).

Cheers,

Sam

On Sat, Apr 18, 2009 at 7:34 PM, Krishna Sankar (ksankar)
<ksankar at cisco.com> wrote:

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.

Cheers
<k/>


|-----Original Message-----
|From: Andre Merzky [mailto:andremerzky at gmail.com] On Behalf Of Andre
|Merzky
|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
|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
<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-%0A%7Cwg/wiki/Re
gis> 
|>    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
<http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-%0A%7Cwg/wiki/Re
gistries> 
|>    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.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090418/0f25b4f8/attachment.html