[occi-wg] Nouns and Verbs (was: Syntax of OCCI API)
Ignacio Martin Llorente
llorente at dacya.ucm.es
Fri Apr 17 08:20:49 CDT 2009
In Reservoir, for the design of the VMI (new Cloud Interface on top of
OpenNebula) we used the states in DMTF DSP2013:
INITIAL
DEFINED
ACTIVE
PAUSED
SUSPENDED
DESTROYED
Please see diagram in page 25 of http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf
Regards
--
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 17/04/2009, at 15:13, Sam Johnston wrote:
> I've been working from a dead tree version which I'll convert to SVG
> asap.
>
> Sam
>
> On Fri, Apr 17, 2009 at 2:49 PM, Edmonds, AndrewX <andrewx.edmonds at intel.com
> > wrote:
> Good question! OVF has a software lifecycle [1] that begins at
> package/distribute and moves to a deploy phase. I feel we can insert
> and relate many of our ideas after the OVF-deploy phase, which is
> Manage.
>
> Andy
>
> [1] page 2 of http://www.dmtf.org/initiatives/vman_initiative/OVF_Tech_Note_Digital.pdf
>
>
> -----Original Message-----
> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On
> Behalf Of Alexis Richardson
> Sent: 17 April 2009 13:32
> To: Andre Merzky
> Cc: occi-wg at ogf.org
> Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API)
>
> +1 to state model for lifecycle. In my experience having one makes a
> compelling improvement to the plausibility and understandability of a
> protocol.
>
> Q: should the lifecycle have a relationship with OVF lifecycle?
>
>
> On Fri, Apr 17, 2009 at 1:27 PM, Andre Merzky <andre at merzky.net>
> wrote:
> >
> > Quoting [Sam Johnston] (Apr 17 2009):
> >>
> >> On Fri, Apr 17, 2009 at 1:18 PM, Edmonds, AndrewX
> >> <[1]andrewx.edmonds at intel.com> wrote:
> >>
> >> Ah! As always the devilish details! :-)
> >> Such important nuances, I believe, can be supported via
> attribute
> >> (just a parameter) of the verb:
> >> e.g. stop (GRACEFUL) or stop(KILL)
> >> where the parameters wrt the stop verb are defined by a
> >> restriction/enumeration. This too supports the restart verb
> (b).
> >>
> >> So a client should probably know where to find basic buttons
> like
> >> "start" and "stop" without having to know all the permutations
> >> (including others yet to be invented relating to live
> migrations and
> >> the like). Parameters are one way to implement this but they
> increase
> >> complexity... maybe just "stop" for the most sensible approach
> for the
> >> given infrastructure (ranging from pinging a daemon to ask for a
> >> graceful shutdown to yanking the cord for physical servers), and
> >> "stop/graceful" etc. for more nuanced versions.
> >
> > A client can always map from a complex API to a simple
> > (G)UI. It should not be problem to have a single STOP
> > button, and when pressing that to perform a couple of API
> > calls with more diverse semantics?
> >
> >
> >> Let's flesh out the options first...
> >>
> >> > (a) What state is a server in when it is created?
> >>
> >> Well won't the result of a POST to server/create utilise
> HATEOAS or
> >> something similar? The result should contain information
> pertaining
> >> to the state of the resultant action.
> >>
> >>
> >> Agreed, most actions should return [pointers to] resources and
> from
> >> there you can tell whether you're "stopped", "starting" or
> "started"
> >> and you'll know what transitions are available to you.
> >
> > BTW: we should start to draft a state model...
> >
> > Oh well, I don't have a candidate, really, but here is food
> > for discussion:
> >
> > New --> Running --> Stopped
> >
> > Running <--> Suspended
> > Running <--> Migrating
> >
> > Andre.
> >
> >
> >> Sam
> >>
> >> -----Original Message-----
> >> From: Chris Webb [mailto:[2]chris.webb at elastichosts.com]
> >> Sent: 17 April 2009 12:06
> >> To: Sam Johnston
> >> Cc: Edmonds, AndrewX; Andre Merzky; [3]occi-wg at ogf.org
> >> Subject: Re: Nouns and Verbs (was: Syntax of OCCI API)
> >> Sam Johnston <[4]samj at samj.net> writes:
> >> > Ok so nouns and verbs (ignoring CRUD which is common anyway):
> >> >
> >> > server:
> >> > - start
> >> > - stop
> >> > - restart
> >> > - deploy/undeploy? (comes back to persistent vs ephemeral
> etc.)
> >> > - clone/snapshot?
> >> Tackling just this one first, there are two core semantic
> issues:
> >> 1. Ephemoral vs persistent servers
> >> There will be providers that only have a concept of servers in
> the
> >> running
> >> state (e.g. Amazon), providers with a concept of stopped/
> shutdown vms
> >> (e.g.
> >> GoGrid) and clouds that want to implement both.
> >> 2. What's possible from outside in a virtualisation environment
> >> We think the (complete?) list of user-visible 'things you can
> do to a
> >> vm'
> >> are ACPI power button press, reset signal, kill the machine,
> pause the
> >> machine and suspend/hibernate the vm to disk. Providers will
> implement
> >> some
> >> subset of these, and of course machines can also reboot and
> >> shutdown/power-off from within, independently of the API.
> These reflect
> >> on
> >> the operations we can support, and how their behaviours can
> reasonably
> >> be
> >> defined.
> >> (a) What state is a server in when it is created? In Amazon's
> case,
> >> there's
> >> only one state if the server exists---it's running. However, a
> more
> >> general
> >> provider like GoGrid can have guests in a stopped state, and
> we might
> >> reasonably want to be able to create them stopped, especially
> when
> >> implementing a web interface. This means that if we want to
> support
> >> stopped
> >> servers at all, we really need to be able to specify the desired
> >> initial
> >> state of server when creating it, e.g.
> >> POST /server/create
> >> state stopped
> >> cpu 1000
> >> [...]
> >> (b) Whilst there is only really one meaning of 'start' and
> only one
> >> (implementable) meaning of 'reset'/'restart', there are two
> varieties
> >> of
> >> stop that we might want to expose: a graceful shutdown (which
> might be
> >> implemented by an ACPI power-down event for example) and a
> hard kill of
> >> the
> >> VM. Which sort of stop a 'destroy' does also needs to be
> specified. I
> >> think
> >> there's also a hibernate or suspend operation that some
> providers might
> >> want
> >> to export.
> >> (c) What happens when a virtual machine powers-off from
> within? A
> >> provider
> >> like Amazon has only one behaviour they can exhibit: shutdown
> = stop =
> >> destroy. However, people who support persistent servers might
> want to
> >> yield
> >> a server in a stopped state instead. To get predictable
> behaviour,
> >> there
> >> probably needs to be a property of a server which indicates
> whether
> >> it's
> >> supposed to persist or be one-shot.
> >> Is the complete operation list perhaps something like
> >> [usual create / info / set / destroy ]
> >> start
> >> kill
> >> shutdown
> >> suspend
> >> reset
> >> where destroy probably wants to be equivalent to a kill in
> effect, and
> >> with
> >> a boolean 'persist' server property that determines when a
> server moves
> >> to a
> >> stopped state or is deleted following a shutdown from the API or
> >> within.
> >> (This can clearly only be false for people like Amazon.)
> >> What did you have in mind for deploy and undeploy? I can see
> how they
> >> might
> >> be identical to either start/stop or create/destroy, but I
> guess you
> >> intend
> >> another meaning?
> >> Let's discuss clone/snapshot later once we have some firmer
> ideas about
> >> the
> >> core stuff.
> >> Cheers,
> >> Chris.
> >>
> >> -------------------------------------------------------------
> >> Intel Ireland Limited (Branch)
> >> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> >> Registered Number: E902934
> >> This e-mail and any attachments may contain confidential
> material for
> >> the sole use of the intended recipient(s). Any review or
> distribution
> >> by others is strictly prohibited. If you are not the intended
> >> recipient, please contact the sender and delete all copies.
> >>
> >> References
> >>
> >> 1. mailto:andrewx.edmonds at intel.com
> >> 2. mailto:chris.webb at elastichosts.com
> >> 3. mailto:occi-wg at ogf.org
> >> 4. mailto:samj at samj.net
> >
> >
> >
> > --
> > Nothing is ever easy.
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> >
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
> -------------------------------------------------------------
> Intel Ireland Limited (Branch)
> Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> Registered Number: E902934
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>
> _______________________________________________
> 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