[occi-wg] OCCI MC - State Machine Diagram
Ignacio Martin Llorente
llorente at dacya.ucm.es
Sun Apr 19 05:16:43 CDT 2009
Hi,
I am not sure what is the state of this discussion, but I would like
to support the addition of ENTRY and EXIT points to the diagram.
Moreover, if we do not assume that the submitted VMs have to run
immediately or not at all, I would like to suggest that we need a
"Pending" state in the diagram. The new submitted VMs remain in this
state until there are resources available. That could be the "DEFINED"
state or the DMTF "INITIAL" state.
Cheers,
Ignacio
--
Ignacio M. Llorente, Full Professor (Catedratico): web http://dsa-research.org/llorente
and blog http://imllorente.dsa-research.org/
DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
On 18/04/2009, at 20:26, Krishna Sankar (ksankar) wrote:
> 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/start
> " 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/restart
> " rel="http://purl.org/occi/state#restart"/>
>
>
>
> <atom:link title="Suspend" href="http://example.com/decca5a5-8952-4004-9793-cdbbf05c3c63/state/suspend
> " 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
> |> 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.
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
More information about the occi-wg
mailing list