Hi, Can we put this in the wiki and may also add a new page about this topic there? so the discussion threads won't get that long? Didn't want to interrupt though :-), All the best, -Thijs On Fri, 2009-04-17 at 11:31 +0100, Edmonds, AndrewX wrote:

Nice J

You have me convinced on dropping of explicit physical/virtual attributes and bounding what is provisioned to a customer with an SLA. I would certainly see that inclusion of “machine readable” SLAs that can be processed by a client and monitored & verified via the Performance Monitoring (PM) be hugely beneficial – not only from the provider point of view (optimisation etc) but also from the customer point of view (assurance, accountability etc). There would certainly be on going work here in the OGF WS-Agreement WG that could possibly provide some input on this.

I’ve put the nouns and verbs into a very simple UML diagram (attached – will place on wiki if people are comfortable with expressing {noun{verb{attribute}}} OCCI vectors)

HTH.

Andy

From: Sam Johnston [mailto:samj@samj.net] Sent: 17 April 2009 10:45 To: Edmonds, AndrewX Cc: Andre Merzky; Chris Webb; occi-wg@ogf.org Subject: Nouns and Verbs (was: Syntax of OCCI API)

Ok so moving right along...

I like the "resource" approach (thanks Andy) and it fits well with the single entry point w/ search style (which in turn allows for arbitrarily simple and complex environments ranging from 1 to many millions of resources). These have a category/type (e.g. server, network, storage) and content depending on that. You can of course ask for just one type or another (e.g. query "servers" but not networks or storage) and we can do a simple optimisation to bring this into line with existing APIs:

http://example.com/servers -> http://example.com/-/server http://example.com/networks -> http://example.com/-/network http://example.com/storage -> http://example.com/-/storage

I specifically don't like the idea of differentiating between physical and virtual resources (the whole point is that you can't, or at least don't need to, know the difference), but that's ok because I don't think it's necessary. If I'm dealing with a "server" I don't care if it's delivered as a slice, a VM or a physical machine so long as it meets my service level agreement.... this is details for the implementor and one of the areas where we need to allow them to innovate.

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? network: - start (aka up) - stop (aka down) storage: - start (aka online) - stop (aka offline) - snapshot? - backup? others?

Sam

---------- Forwarded message ---------- From: Edmonds, AndrewX <andrewx.edmonds@intel.com> Date: Fri, Apr 17, 2009 at 11:10 AM Subject: Re: [occi-wg] Syntax of OCCI API To: Andre Merzky <andre@merzky.net>, Chris Webb <chris.webb@elastichosts.com> Cc: "occi-wg@ogf.org" <occi-wg@ogf.org>

Exactly my point in my last mail, Andre. If we can even begin to suggest on the nouns that'll be a big help. In the wiki we have the central entity to be a "Resource" (in fact we could name this as Noun to focus discussion - thoughts? Sam?. That "Resource"/"Noun" can be abstractly sub-classed as virtual or physical and beneath that concrete entities could be "Server", "VM" and in the case of extension (re: Randy), "Loadbalancer".

Andy

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 17 April 2009 10:03 To: Chris Webb Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Syntax of OCCI API

Once we get the noun/verb/attribute part settled, there is no harm in doing an ini and a key/val binding. In fact, a translator would be trivial...

You can argue endlessly about the better format: there are too many PROs and CONs for both of them to come to an conclusive answer, IMHO.

My $0.02, Andre.

------------------------------------------------------------- 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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

Morning, I generally agree that we should look at existing work but for many use cases the demands are things like: - I want 5 nines - I want a machine in the EU - I need a persistent disk - I need fast RAM - I need burstable CPU I think a lot of this information can be captured along with simple machine configuration (e.g. "location: eu") but if users want to send XML agreements (and providers want to differentiate themselves by accepting them) then so be it... transparent representation and transportation is one of the many advantages of supporting XML at the core. Being able to request/require certain disk/memory bandwidths could be an interesting way to level the playing field a bit too... otherwise a system with DDR3 looks the same from the outside as one using mercury delay lines... Sam On Tue, Apr 21, 2009 at 11:09 AM, Alexander Papaspyrou < alexander.papaspyrou@tu-dortmund.de> wrote:

Regarding machine-readable SLAs, we should look at GRAAP -- as Andy already stated. They defined along with WS-Agreement data formats for the port type which hold an SLA on whatever you can think of.

The downside is that WS-Agreement is designed in a super-flexible way, and if we'd like to incorporate it somehow into OCCI, we'd probably have to do a rendering. The other thing is that WS-Agreement -- at least to the moment -- is bound do WSRF. This also could be addressed (ending up with a REST rendering of it), but -- to my best knowledge as a member of the group -- currently there are no plans in GRAAP to do something like that.

-Alexander

Am 17.04.2009 um 12:31 schrieb Edmonds, AndrewX:

Nice J

...

You have me convinced on dropping of explicit physical/virtual attributes and bounding what is provisioned to a customer with an SLA. I would certainly see that inclusion of “machine readable” SLAs that can be processed by a client and monitored & verified via the Performance Monitoring (PM) be hugely beneficial – not only from the provider point of view (optimisation etc) but also from the customer point of view (assurance, accountability etc). There would certainly be on going work here in the OGF WS-Agreement WG that could possibly provide some input on this.

I’ve put the nouns and verbs into a very simple UML diagram (attached – will place on wiki if people are comfortable with expressing {noun{verb{attribute}}} OCCI vectors)

HTH.

Andy

From: Sam Johnston [mailto:samj@samj.net] Sent: 17 April 2009 10:45 To: Edmonds, AndrewX Cc: Andre Merzky; Chris Webb; occi-wg@ogf.org Subject: Nouns and Verbs (was: Syntax of OCCI API)

Ok so moving right along...

I like the "resource" approach (thanks Andy) and it fits well with the single entry point w/ search style (which in turn allows for arbitrarily simple and complex environments ranging from 1 to many millions of resources). These have a category/type (e.g. server, network, storage) and content depending on that. You can of course ask for just one type or another (e.g. query "servers" but not networks or storage) and we can do a simple optimisation to bring this into line with existing APIs:

http://example.com/servers -> http://example.com/-/server http://example.com/networks -> http://example.com/-/network http://example.com/storage -> http://example.com/-/storage

I specifically don't like the idea of differentiating between physical and virtual resources (the whole point is that you can't, or at least don't need to, know the difference), but that's ok because I don't think it's necessary. If I'm dealing with a "server" I don't care if it's delivered as a slice, a VM or a physical machine so long as it meets my service level agreement.... this is details for the implementor and one of the areas where we need to allow them to innovate.

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? network: - start (aka up) - stop (aka down) storage: - start (aka online) - stop (aka offline) - snapshot? - backup? others?

Sam ---------- Forwarded message ---------- From: Edmonds, AndrewX <andrewx.edmonds@intel.com> Date: Fri, Apr 17, 2009 at 11:10 AM Subject: Re: [occi-wg] Syntax of OCCI API To: Andre Merzky <andre@merzky.net>, Chris Webb < chris.webb@elastichosts.com> Cc: "occi-wg@ogf.org" <occi-wg@ogf.org>

Exactly my point in my last mail, Andre. If we can even begin to suggest on the nouns that'll be a big help. In the wiki we have the central entity to be a "Resource" (in fact we could name this as Noun to focus discussion - thoughts? Sam?. That "Resource"/"Noun" can be abstractly sub-classed as virtual or physical and beneath that concrete entities could be "Server", "VM" and in the case of extension (re: Randy), "Loadbalancer".

Andy

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 17 April 2009 10:03 To: Chris Webb Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Syntax of OCCI API Once we get the noun/verb/attribute part settled, there is no harm in doing an ini and a key/val binding. In fact, a translator would be trivial...

You can argue endlessly about the better format: there are too many PROs and CONs for both of them to come to an conclusive answer, IMHO.

My $0.02, Andre.

------------------------------------------------------------- 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-Nouns&Verbs.png>_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de

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).

(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.

Andy -----Original Message----- From: Chris Webb [mailto:chris.webb@elastichosts.com] Sent: 17 April 2009 12:06 To: Sam Johnston Cc: Edmonds, AndrewX; Andre Merzky; occi-wg@ogf.org Subject: Re: Nouns and Verbs (was: Syntax of OCCI API) Sam Johnston <samj@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.

On Fri, Apr 17, 2009 at 1:18 PM, Edmonds, AndrewX <andrewx.edmonds@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. 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. Sam -----Original Message-----

From: Chris Webb [mailto:chris.webb@elastichosts.com] Sent: 17 April 2009 12:06 To: Sam Johnston Cc: Edmonds, AndrewX; Andre Merzky; occi-wg@ogf.org Subject: Re: Nouns and Verbs (was: Syntax of OCCI API)

Sam Johnston <samj@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.

+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@merzky.net> wrote:

Quoting [Sam Johnston] (Apr 17 2009):

...

   On Fri, Apr 17, 2009 at 1:18 PM, Edmonds, AndrewX    <[1]andrewx.edmonds@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@elastichosts.com]    Sent: 17 April 2009 12:06    To: Sam Johnston    Cc: Edmonds, AndrewX; Andre Merzky; [3]occi-wg@ogf.org    Subject: Re: Nouns and Verbs (was: Syntax of OCCI API)    Sam Johnston <[4]samj@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@intel.com    2. mailto:chris.webb@elastichosts.com    3. mailto:occi-wg@ogf.org    4. mailto:samj@samj.net

-- Nothing is ever easy. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

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@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@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf
> Of Alexis Richardson
> Sent: 17 April 2009 13:32
> To: Andre Merzky
> Cc: occi-wg@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@merzky.net> wrote:
> >
> > Quoting [Sam Johnston] (Apr 17 2009):
> >>
> >>    On Fri, Apr 17, 2009 at 1:18 PM, Edmonds, AndrewX
> >>    <[1]andrewx.edmonds@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@elastichosts.com]
> >>    Sent: 17 April 2009 12:06
> >>    To: Sam Johnston
> >>    Cc: Edmonds, AndrewX; Andre Merzky; [3]occi-wg@ogf.org
> >>    Subject: Re: Nouns and Verbs (was: Syntax of OCCI API)
> >>    Sam Johnston <[4]samj@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@intel.com
> >>    2. mailto:chris.webb@elastichosts.com
> >>    3. mailto:occi-wg@ogf.org
> >>    4. mailto:samj@samj.net
> >
> >
> >
> > --
> > Nothing is ever easy.
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg@ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> >
> _______________________________________________
> occi-wg mailing list
> occi-wg@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@ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
>

Quoting [Edmonds, AndrewX] (Apr 17 2009):
> 
> 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.

This is excellent!  In the best tradition of extensible OGF
state models, we would be defining substates of the
OVF:Manage state...

Andre.


> Andy
> 
> [1] page 2 of http://www.dmtf.org/initiatives/vman_initiative/OVF_Tech_Note_Digital.pdf
> 
> 
> -----Original Message-----
> From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Alexis Richardson
> Sent: 17 April 2009 13:32
> To: Andre Merzky
> Cc: occi-wg@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@merzky.net> wrote:
> >
> > Quoting [Sam Johnston] (Apr 17 2009):
> >>
> >>    On Fri, Apr 17, 2009 at 1:18 PM, Edmonds, AndrewX
> >>    <[1]andrewx.edmonds@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@elastichosts.com]
> >>    Sent: 17 April 2009 12:06
> >>    To: Sam Johnston
> >>    Cc: Edmonds, AndrewX; Andre Merzky; [3]occi-wg@ogf.org
> >>    Subject: Re: Nouns and Verbs (was: Syntax of OCCI API)
> >>    Sam Johnston <[4]samj@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@intel.com
> >>    2. mailto:chris.webb@elastichosts.com
> >>    3. mailto:occi-wg@ogf.org
> >>    4. mailto:samj@samj.net
> >
> >
> >
> > --
> > Nothing is ever easy.
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg@ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> >
> _______________________________________________
> occi-wg mailing list
> occi-wg@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.



-- 
Nothing is ever easy.

Quoting [Thijs Metsch] (Apr 17 2009):

Good idea:

...

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

Installed --> Starting --> Running --> Stopping --> Stopped \---> Suspended --> Starting --> Running \---> Migrated \---> Copied

some questions: - How is Copied different from Running? - Is Migrating needed, i.e. does the process involve service degradation?

Hope this nice piece of ASCII arts survives :-)

yep :-) A. -- Nothing is ever easy.

Thijs Metsch <Thijs.Metsch@Sun.COM> writes:

Well I'm not sure if copied and running are really different but it might be interesting to know that a machine is copied (Although I cannot think of a usecase right now).

Concerning the migrating I think that depends on how the VM is migrate (live or not) To cover both I think adding a state is useful.

These seem like rather poor reasons to complicate the state model to me. Cheers, Chris.

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API 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 14:49, Chris Webb wrote:

Thijs Metsch <Thijs.Metsch@Sun.COM> writes:

...

Installed --> Starting --> Running --> Stopping --> Stopped \---> Suspended --> Starting --> Running \---> Migrated \---> Copied

Hope this nice piece of ASCII arts survives :-)

It did! Could you clarify how 'migrated' and 'copied' differ from 'running'? (Migration of VMs within a cloud for load-balancing is something that should surely be completely user-transparent. Is this intended for some other purpose?)

Also, I don't follow what your 'installed' and 'starting' states are for. Surely our virtual machine is either running or not: we can't distinguish from outside whether a guest OS has fully started or not, even if we believe such a distinction is well-defined.

Cheers,

Chris.

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

I updated the wiki page...more like this then? Feel free to alter! -Thijs On Fri, 2009-04-17 at 15:14 +0200, Lars Larsson wrote:

On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:

...

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API

I fully agree with Ignacio.

I think there is a difference between the set of states that a VM can be in, and the set of states that may be set using the API. The first set may be larger and include informational states such as "being migrated" or "being copied", but that does not mean that the user can actively request that a VM should be migrated.

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

Displaying extra information, such as "being migrated" or "being copied" is up to the infrastructure provider to optionally add to the description of the state that is reported via monitoring.

Best regards,

-- Lars _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

Suggestion: Maybe move to simple UML diagram editor? -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Thijs Metsch Sent: 17 April 2009 14:31 To: occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model This time the ASCII art on the wiki didn't survive (added another view) -Thijs On Fri, 2009-04-17 at 15:21 +0200, Thijs Metsch wrote:

I updated the wiki page...more like this then?

Feel free to alter!

-Thijs

On Fri, 2009-04-17 at 15:14 +0200, Lars Larsson wrote:

...

On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:

...

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API

I fully agree with Ignacio.

I think there is a difference between the set of states that a VM can be in, and the set of states that may be set using the API. The first set may be larger and include informational states such as "being migrated" or "being copied", but that does not mean that the user can actively request that a VM should be migrated.

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

Displaying extra information, such as "being migrated" or "being copied" is up to the infrastructure provider to optionally add to the description of the state that is reported via monitoring.

Best regards,

-- Lars _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

_______________________________________________ occi-wg mailing list occi-wg@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.

Have done so... I mailed direct the UML I posted earlier to the list to Sam for modification. I've placed what I sent here [1]. State diagram not included Andy [1] http://forge.ogf.org/sf/go/doc15611?nav=1 -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Thijs Metsch Sent: 17 April 2009 14:40 To: occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model Good idea, Can you draw something and add it to the wiki page? -Thijs On Fri, 2009-04-17 at 14:32 +0100, Edmonds, AndrewX wrote:

Suggestion: Maybe move to simple UML diagram editor?

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Thijs Metsch Sent: 17 April 2009 14:31 To: occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model

This time the ASCII art on the wiki didn't survive (added another view)

-Thijs

On Fri, 2009-04-17 at 15:21 +0200, Thijs Metsch wrote:

...

I updated the wiki page...more like this then?

Feel free to alter!

-Thijs

On Fri, 2009-04-17 at 15:14 +0200, Lars Larsson wrote:

...

On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:

...

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API

I fully agree with Ignacio.

I think there is a difference between the set of states that a VM can be in, and the set of states that may be set using the API. The first set may be larger and include informational states such as "being migrated" or "being copied", but that does not mean that the user can actively request that a VM should be migrated.

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

Displaying extra information, such as "being migrated" or "being copied" is up to the infrastructure provider to optionally add to the description of the state that is reported via monitoring.

Best regards,

-- Lars _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

_______________________________________________ occi-wg mailing list occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

_______________________________________________ occi-wg mailing list occi-wg@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.

My bad - sorry Chris... I made a note of how to edit in the description of the file. I have been using a UML editor by the name of Jude [1] (community version). Now it doesn’t quite support XMI, hence the funky format (it's a zip file - see the 'PK' header). But that being said XMI import/export functionality doesn’t work too well in my experience, especially when neither version of it supports capturing and persisting how a diagram is laid out. Andy [1] jude.change-vision.com -----Original Message----- From: Chris Webb [mailto:chris.webb@elastichosts.com] Sent: 17 April 2009 14:55 To: Edmonds, AndrewX Cc: Thijs Metsch; occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model "Edmonds, AndrewX" <andrewx.edmonds@intel.com> writes:

Have done so... I mailed direct the UML I posted earlier to the list to Sam for modification. I've placed what I sent here [1]. State diagram not included

How would one read or edit this? It appears to be an opaque binary file, and hexdump provides no clues! 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.

On Fri, Apr 17, 2009 at 3:23 PM, Tino Vazquez <tinova@fdi.ucm.es> wrote:

IMHO I think "migrating" and/or "migrated" are states that doesn't make sense under the point of view of a Cloud API, this should be something internal completely transparent to the user. Also, I am not sure that we need the "copied" state. What does it mean exactly?

Aside from that I kind of like the model. I would suggest adding a "suspending" state (or "saving" since it presumabley the VM is going to dump a snapshot) and also a "finished" state and "failed" state to handle errors.

What do you think?

My dead tree version has states like: STOPPED RESTORING/STARTING STARTED SUSPENDING/STOPPING It was derived (at least in part) from the Microsoft Virtual Server state diagram <http://msdn.microsoft.com/en-us/library/aa368893%28VS.85%29.aspx>. As a user of cloud services giving sensible and consistent visual feedback during the state changes is *very* important for the user experience. Sam

My position is that if DMTF already provides a life-cycle model, we should adopt it as long as it meets the requirements from use cases. 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 16:21, Andre Merzky wrote:

Quoting [Lars Larsson] (Apr 17 2009):

...

On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:

...

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API

I fully agree with Ignacio.

I think there is a difference between the set of states that a VM can be in, and the set of states that may be set using the API. The first set may be larger and include informational states such as "being migrated" or "being copied", but that does not mean that the user can actively request that a VM should be migrated.

Yes, I agree with that: active versus informational states. Again, other state models in OGF represent such information as substates, e.g. 'Migrating' might be expressed as a substate of 'Running'. I am not saying this is how this group should do state modeling, just for information...

...

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

That is an interesting model - it seems a lot of people have been thinking hard about that :-) I like it...

To play the devils advocate though:

- Is that state model suitable for our use cases? It seems to allow for quite a large number of transissions, but is missing the 'Initial -> Suspended' transition which has been discussed on this list earlier.

- The design seems to have been motivated by physical states rather than logical states (the power state notes are an artifact of that I guess?). Are the states applicable to our use cases?

- Do we need a distinction between 'VS State' and 'Enabled State'? The document says: " the EnabledState property represents the virtual system’s state" - so, what is the difference to VS state, which is, I take, also the virtual system state? The document does not offer a better definition/distinction AFICS.

...

Displaying extra information, such as "being migrated" or "being copied" is up to the infrastructure provider to optionally add to the description of the state that is reported via monitoring.

+1

Best, Andre.

-- Nothing is ever easy.

This is what VMware have (had) to say on the subject: http://pubs.vmware.com/vi-sdk/visdk250/ReferenceGuide/vim.vm.GuestInfo.Guest... notRunning, resetting, running, shuttingDown, standby, unknown We're going to have to be very careful with this because if we're to expect providers like VMware, MS, Citrix, etc. to implement this stuff then we're going to want to make it as easy as possible (which means not stripping out states they [think they] need or relying on states they don't have). Sam On Fri, Apr 17, 2009 at 4:21 PM, Andre Merzky <andre@merzky.net> wrote:

Quoting [Lars Larsson] (Apr 17 2009):

...

On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:

...

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API

I fully agree with Ignacio.

I think there is a difference between the set of states that a VM can be in, and the set of states that may be set using the API. The first set may be larger and include informational states such as "being migrated" or "being copied", but that does not mean that the user can actively request that a VM should be migrated.

Yes, I agree with that: active versus informational states. Again, other state models in OGF represent such information as substates, e.g. 'Migrating' might be expressed as a substate of 'Running'. I am not saying this is how this group should do state modeling, just for information...

...

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

That is an interesting model - it seems a lot of people have been thinking hard about that :-) I like it...

To play the devils advocate though:

- Is that state model suitable for our use cases? It seems to allow for quite a large number of transissions, but is missing the 'Initial -> Suspended' transition which has been discussed on this list earlier.

- The design seems to have been motivated by physical states rather than logical states (the power state notes are an artifact of that I guess?). Are the states applicable to our use cases?

- Do we need a distinction between 'VS State' and 'Enabled State'? The document says: " the EnabledState property represents the virtual system’s state" - so, what is the difference to VS state, which is, I take, also the virtual system state? The document does not offer a better definition/distinction AFICS.

...

Displaying extra information, such as "being migrated" or "being copied" is up to the infrastructure provider to optionally add to the description of the state that is reported via monitoring.

+1

Best, Andre.

-- Nothing is ever easy. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

Ok so now that thing have quietened down a bit and I've had some time to reflect I think there's a better way. Things like state diagrams are surprisingly emotive. People have a mental of how things [should] work and they like the products they use to fit that picture. Some people don't care about intermediary states like "starting" but others (like me) don't have the patience to sit around waiting for results without feedback. My point is that for every one of us there's probably two potential solutions to this problem. We need to standardise so that people can interoperate. If I see a machine that is "stopped" there should be a "start" button and vice versa, but beyond that we don't need to say much. Another facet is that we don't know every use case for this API so people need to be able to extend it, and if they are going to do so then they should do it in a coordinated fashion. Someone may want to add a "transmogrifying" state to indicate that an OVF machine is being converted to the native format (which can take a while). Some other sick and twisted individual might decide to implement live migrations over SMTP for those special "enterprise environments" so they want to have a "sending" and "receiving" state - in fact these could already be useful for transferring workloads between implementations. The single best way for us to solve this is to specify what we need to specify for the level of interoperability we plan to achieve and then maintain a registry for everything else. That allows us to be minimalist in the API spec itself and pre-populate the registry with informative states like "[re]starting", "restoring", etc. Another potentially interesting enhancement is feedback in terms of progress, ETAs, etc. as these tend to be critical for user experience... particularly clever providers might track the average startup time for a certain machine for example and expose this so the client can run a (relatively accurate) progress bar. Sam On Fri, Apr 17, 2009 at 4:56 PM, Lars Larsson <larsson@cs.umu.se> wrote:

...

...

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

That is an interesting model - it seems a lot of people have been thinking hard about that :-) I like it...

To play the devils advocate though:

- Is that state model suitable for our use cases? It seems to allow for quite a large number of transissions, but is missing the 'Initial -> Suspended' transition which has been discussed on this list earlier.

- The design seems to have been motivated by physical states rather than logical states (the power state notes are an artifact of that I guess?). Are the states applicable to our use cases?

My interpretation of the CIM set of states is that the "Initial" state is a state that the VM has before it has even been defined or been allocated resources at the (virtual) hardware level. Such a system has never been in a previous state, and so cannot reasonably go to any other state than that of a shut down system with no prior state from which it has been suspended.

I agree that this type of state model may be insufficient, e.g. because it is possible that we want to be able to submit a VM that has indeed been running somewhere else into the cloud (so while it is new to the cloud, it *does* have a prior state and is currently suspended).

Such special scenarios may of course be supported by allowing a state definition to be made upon submission of the VM to the cloud infrastructure, but doing so certainly circumvents the semantics of the CIM model.

...

- Do we need a distinction between 'VS State' and 'Enabled State'? The document says: " the EnabledState property represents the virtual systemâ??s state" - so, what is the difference to VS state, which is, I take, also the virtual system state? The document does not offer a better definition/distinction AFICS.

This is again just my interpretation, but I think that the EnabledState is used to denote that the VM actively requires resources from the hypervisor of some sort, whereas the VS (Virtual System) state is the state from the point of view of the user and guest operating system (and PowerState is the mapping to physical hardware, which seems to have been a great inspiration to the creators of the model, I agree).

So to answer your question if we need them a distinction or not -- no, we do not. If my interpretation is correct, the different kinds of state are just different perspectives of the same thing, so there is no actual distinction to begin with.

-- Lars _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

Agreed *10 and don't forget Gall's Law :-) There is also currently a big gap between requirement extraction from use cases passing on into the API design so process-wise there's a piece of continuity massaging to be done. On use cases, I've been talking to the lead of the use case specifications within SLA@SOI (helps that he sits across from me) and it should be possible to have more specific use cases contributed from us in SLA@SOI Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Alexis Richardson Sent: 17 April 2009 17:26 To: Sam Johnston Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model +1,000 to "mimimalist" At least until we know more about what we are doing. On Fri, Apr 17, 2009 at 5:22 PM, Sam Johnston <samj@samj.net> wrote:

Ok so now that thing have quietened down a bit and I've had some time to reflect I think there's a better way.

Things like state diagrams are surprisingly emotive. People have a mental of how things [should] work and they like the products they use to fit that picture. Some people don't care about intermediary states like "starting" but others (like me) don't have the patience to sit around waiting for results without feedback. My point is that for every one of us there's probably two potential solutions to this problem. We need to standardise so that people can interoperate. If I see a machine that is "stopped" there should be a "start" button and vice versa, but beyond that we don't need to say much.

Another facet is that we don't know every use case for this API so people need to be able to extend it, and if they are going to do so then they should do it in a coordinated fashion. Someone may want to add a "transmogrifying" state to indicate that an OVF machine is being converted to the native format (which can take a while). Some other sick and twisted individual might decide to implement live migrations over SMTP for those special "enterprise environments" so they want to have a "sending" and "receiving" state - in fact these could already be useful for transferring workloads between implementations.

The single best way for us to solve this is to specify what we need to specify for the level of interoperability we plan to achieve and then maintain a registry for everything else. That allows us to be minimalist in the API spec itself and pre-populate the registry with informative states like "[re]starting", "restoring", etc.

Another potentially interesting enhancement is feedback in terms of progress, ETAs, etc. as these tend to be critical for user experience... particularly clever providers might track the average startup time for a certain machine for example and expose this so the client can run a (relatively accurate) progress bar.

Sam

On Fri, Apr 17, 2009 at 4:56 PM, Lars Larsson <larsson@cs.umu.se> wrote:

...

...

...

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

That is an interesting model - it seems a lot of people have been thinking hard about that :-) I like it...

To play the devils advocate though:

- Is that state model suitable for our use cases? It seems to allow for quite a large number of transissions, but is missing the 'Initial -> Suspended' transition which has been discussed on this list earlier.

- The design seems to have been motivated by physical states rather than logical states (the power state notes are an artifact of that I guess?). Are the states applicable to our use cases?

My interpretation of the CIM set of states is that the "Initial" state is a state that the VM has before it has even been defined or been allocated resources at the (virtual) hardware level. Such a system has never been in a previous state, and so cannot reasonably go to any other state than that of a shut down system with no prior state from which it has been suspended.

I agree that this type of state model may be insufficient, e.g. because it is possible that we want to be able to submit a VM that has indeed been running somewhere else into the cloud (so while it is new to the cloud, it *does* have a prior state and is currently suspended).

Such special scenarios may of course be supported by allowing a state definition to be made upon submission of the VM to the cloud infrastructure, but doing so certainly circumvents the semantics of the CIM model.

...

- Do we need a distinction between 'VS State' and 'Enabled State'? The document says: " the EnabledState property represents the virtual systemâ??s state" - so, what is the difference to VS state, which is, I take, also the virtual system state? The document does not offer a better definition/distinction AFICS.

This is again just my interpretation, but I think that the EnabledState is used to denote that the VM actively requires resources from the hypervisor of some sort, whereas the VS (Virtual System) state is the state from the point of view of the user and guest operating system (and PowerState is the mapping to physical hardware, which seems to have been a great inspiration to the creators of the model, I agree).

So to answer your question if we need them a distinction or not -- no, we do not. If my interpretation is correct, the different kinds of state are just different perspectives of the same thing, so there is no actual distinction to begin with.

-- Lars _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

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

_______________________________________________ occi-wg mailing list occi-wg@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.

In this case, we might look at what OGSA-BES and HPC-BP did: a state model that is fixed in terms of toplevel states and the transitions, but extensible in terms of sub-states without allowing additional (non- toplevel compatible) transistions. -Alexander Am 17.04.2009 um 15:14 schrieb Lars Larsson:

On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:

...

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API

I fully agree with Ignacio.

I think there is a difference between the set of states that a VM can be in, and the set of states that may be set using the API. The first set may be larger and include informational states such as "being migrated" or "being copied", but that does not mean that the user can actively request that a VM should be migrated.

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

Displaying extra information, such as "being migrated" or "being copied" is up to the infrastructure provider to optionally add to the description of the state that is reported via monitoring.

Best regards,

-- Lars _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de

http://www.ogf.org/documents/GFD.108.pdf is the published recommendation on OGSA-BES. See page 7 for details on state extension. -Alexander Am 21.04.2009 um 11:25 schrieb Edmonds, AndrewX:

Nice! Have you any pointers to material on this work, Alexander?

Andy

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Alexander Papaspyrou Sent: 21 April 2009 10:19 To: Lars Larsson Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) - state model

In this case, we might look at what OGSA-BES and HPC-BP did: a state model that is fixed in terms of toplevel states and the transitions, but extensible in terms of sub-states without allowing additional (non- toplevel compatible) transistions.

-Alexander

Am 17.04.2009 um 15:14 schrieb Lars Larsson:

...

On Fri, 17 Apr 2009, Ignacio Martin Llorente wrote:

...

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API

I fully agree with Ignacio.

I think there is a difference between the set of states that a VM can be in, and the set of states that may be set using the API. The first set may be larger and include informational states such as "being migrated" or "being copied", but that does not mean that the user can actively request that a VM should be migrated.

I suggest that we use the states shown at page 25 in "CIM System Virtualization White Paper" by the DMTF (DSP2013), available here:

http://www.dmtf.org/standards/published_documents/DSP2013_1.0.0.pdf

Displaying extra information, such as "being migrated" or "being copied" is up to the infrastructure provider to optionally add to the description of the state that is reported via monitoring.

Best regards,

-- Lars _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de

------------------------------------------------------------- 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.

-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de

Quoting [Ignacio Martin Llorente] (Apr 17 2009):

We do not need "migrated", that is an internal operation that can not be requested using a Cloud API

Do we consider the use case that a user can request additional resources while the instance is Running? In such a case, a user might actually be able to trigger migration. But then again, the resource provisioning is an implementation detail, so Migration may not be what is happening... Anyway, even if migration is an internal process: as long as it affects the provided level of service, the user should be informed about it, I think? Cheers, Andre. -- Nothing is ever easy.

This is a "view" question. From the viewpoint of a scheduler, "migrating" is important; the user certainly does not need (want?) to see this. Are we really clear about the target audience of the API? -Alexander Am 17.04.2009 um 14:49 schrieb Chris Webb:

Thijs Metsch <Thijs.Metsch@Sun.COM> writes:

...

Installed --> Starting --> Running --> Stopping --> Stopped \---> Suspended --> Starting --> Running \---> Migrated \---> Copied

Hope this nice piece of ASCII arts survives :-)

It did! Could you clarify how 'migrated' and 'copied' differ from 'running'? (Migration of VMs within a cloud for load-balancing is something that should surely be completely user-transparent. Is this intended for some other purpose?)

Also, I don't follow what your 'installed' and 'starting' states are for. Surely our virtual machine is either running or not: we can't distinguish from outside whether a guest OS has fully started or not, even if we believe such a distinction is well-defined.

Cheers,

Chris.

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

-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de

Alexander, We are defining an API for end users of cloud infrastructures, and not an API for the dynamic management of VMs in clusters/data centers. I think that the scope is clearly defined in the charter. Thanks -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente 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 21/04/2009, at 11:16, Alexander Papaspyrou wrote:

This is a "view" question. From the viewpoint of a scheduler, "migrating" is important; the user certainly does not need (want?) to see this. Are we really clear about the target audience of the API?

-Alexander

Am 17.04.2009 um 14:49 schrieb Chris Webb:

...

Thijs Metsch <Thijs.Metsch@Sun.COM> writes:

...

Installed --> Starting --> Running --> Stopping --> Stopped \---> Suspended --> Starting --> Running \---> Migrated \---> Copied

Hope this nice piece of ASCII arts survives :-)

It did! Could you clarify how 'migrated' and 'copied' differ from 'running'? (Migration of VMs within a cloud for load-balancing is something that should surely be completely user-transparent. Is this intended for some other purpose?)

Also, I don't follow what your 'installed' and 'starting' states are for. Surely our virtual machine is either running or not: we can't distinguish from outside whether a guest OS has fully started or not, even if we believe such a distinction is well-defined.

Cheers,

Chris.

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

-- Alexander Papaspyrou alexander.papaspyrou@tu-dortmund.de

<Alexander Papaspyrou.vcf>

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

...

...

e.g. stop (GRACEFUL) or stop(KILL) ... 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?

+1 to this follow up. I think we should have API calls which are clear in their meaning and distinguish the different cases (e.g. stop graceful vs. kill) rather than a single stop call with vendor-specific behaviour. Richard.

Simon Wardley wrote:

2. When it comes to stopping and starting servers, aren't these simply attributes of the server. Whether its active state is on or off seems little different from other attributes of that specific resource. ... stopping / starting a server {resource_provider/my_id/servers/some_server {update{state attribute}}

This is an interesting question, and one where we've been both ways with ElasticHosts. Our current approach is that we use updating attributes wherever an action is completed before the call returns, and specific action call wherever an action takes time to handle after the call returns. For example, we use an update to storage's size attribute to resize storage (and the resized storage is available immediately). But on the other hand, we have a specific server shutdown call (rather than updating the server's state) to send an ACPI shutdown message to a server, since we know that it will take significant time for the server's OS to respond to this and shut itself down - during this time period, the server's status is still 'RUNNING'. Cheers, Richard.

If there is consensus on the language Andy just highlighted, please get it on the wiki. On Fri, Apr 17, 2009 at 12:34 PM, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:

+1 +$0.00001 :-)

Excellent principles; "simplify to actual actions on the server resource itself" - yes

" define a range of nouns for common resources, a limited set of verbs for actions and a range of attributes to describe common characteristics." Yes, perfect.

And a resounding yes to the aspect of "attribute changes that are transitory at this moment in time"

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Simon Wardley Sent: 17 April 2009 12:18 To: Sam Johnston Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API)

Hi Sam,

My $0.00001 worth and sorry if these questions / observations are dumb.

...

{noun{verb{attribute}}} vector

+1 for this.

...

I specifically don't like the idea of differentiating between physical and virtual resources

I couldn't agree more with this statement.

The language used should be consistent regardless of the mechanism of implementation of a resource. If I'm using a remote infrastructure service, there should be no reason for me to care how that infrastructure is delivered other than that resource has certain attributes (e.g. persistence etc).

In the format of {noun{verb{attribute}}}

The approach of {resource_provider/my_id/servers {create{attributes}} should simply create a server with the attributes given.

...

Ok so nouns and verbs (ignoring CRUD which is common anyway): storage:  - snapshot?  - backup?

My really dumb questions are:-

1. In the format of {noun{verb{attribute}}}  shouldn't back-up and snapshot simply be:-

{resource_provider/my_id/storage/my_backup_store {update {other_resource_provider/my_id/storage/my_store}}

2. When it comes to stopping and starting servers, aren't these simply attributes of the server. Whether its active state is on or off seems little different from other attributes of that specific resource.

The only reason why we describe a process of stopping or starting a server at this moment in time is because of hardware constraints, but then I'm an old git and remember the 5 minutes or so that I use to have to wait to "park" my winchester drives before switching off the power.

I fully expect future SSD to have near instantaneous changes in state.

So my question is, are we describing verbs for attribute changes that are transitory at this moment in time?

Should we not simplify to actual actions on the server resource itself, i.e. :-

creating a server {resource_provider/my_id/servers {create{attributes}}

deleting a server {resource_provider/my_id/servers/some_server {delete{...}}

reading characteristics of a server {resource_provider/my_id/servers/some_server {read{some attribute}}

cloning a server {resource_provider/my_id/servers/some_server {update{resource_provider/my_id/servers/some_other_server}}

stopping / starting a server {resource_provider/my_id/servers/some_server {update{state attribute}}

list all servers (or servers with a specific attribute such as running) {resource_provider/my_id/servers {read{{...}}

The same seems to be generally true with other resources (i.e. storage, networks, servers etc).

Just my thoughts, I'd define a range of nouns for common resources, a limited set of verbs for actions and a range of attributes to describe common characteristics.

Feel free to ignore me if I've missed the point.

-- Simon Wardley Software Services Manager, Canonical Ltd. TEL: +44 (0)207 630 2451 MOB : +44 (0)7972 911 449 TWITTER: http://www.twitter.com/swardley/

_______________________________________________ occi-wg mailing list occi-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

Have added a "Design Principles" section in the APIDesign wiki page and included contribs from Simon - we can look later to merging these with general requirements from other projects and use cases. Add more where appropriate... Andy -----Original Message----- From: Alexis Richardson [mailto:alexis.richardson@gmail.com] Sent: 17 April 2009 12:47 To: Edmonds, AndrewX Cc: simon.wardley@canonical.com; Sam Johnston; occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API) If there is consensus on the language Andy just highlighted, please get it on the wiki. On Fri, Apr 17, 2009 at 12:34 PM, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:

+1 +$0.00001 :-)

Excellent principles; "simplify to actual actions on the server resource itself" - yes

" define a range of nouns for common resources, a limited set of verbs for actions and a range of attributes to describe common characteristics." Yes, perfect.

And a resounding yes to the aspect of "attribute changes that are transitory at this moment in time"

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Simon Wardley Sent: 17 April 2009 12:18 To: Sam Johnston Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API)

Hi Sam,

My $0.00001 worth and sorry if these questions / observations are dumb.

...

{noun{verb{attribute}}} vector

+1 for this.

...

I specifically don't like the idea of differentiating between physical and virtual resources

I couldn't agree more with this statement.

The language used should be consistent regardless of the mechanism of implementation of a resource. If I'm using a remote infrastructure service, there should be no reason for me to care how that infrastructure is delivered other than that resource has certain attributes (e.g. persistence etc).

In the format of {noun{verb{attribute}}}

The approach of {resource_provider/my_id/servers {create{attributes}} should simply create a server with the attributes given.

...

Ok so nouns and verbs (ignoring CRUD which is common anyway): storage: - snapshot? - backup?

My really dumb questions are:-

1. In the format of {noun{verb{attribute}}} shouldn't back-up and snapshot simply be:-

{resource_provider/my_id/storage/my_backup_store {update {other_resource_provider/my_id/storage/my_store}}

2. When it comes to stopping and starting servers, aren't these simply attributes of the server. Whether its active state is on or off seems little different from other attributes of that specific resource.

The only reason why we describe a process of stopping or starting a server at this moment in time is because of hardware constraints, but then I'm an old git and remember the 5 minutes or so that I use to have to wait to "park" my winchester drives before switching off the power.

I fully expect future SSD to have near instantaneous changes in state.

So my question is, are we describing verbs for attribute changes that are transitory at this moment in time?

Should we not simplify to actual actions on the server resource itself, i.e. :-

creating a server {resource_provider/my_id/servers {create{attributes}}

deleting a server {resource_provider/my_id/servers/some_server {delete{...}}

reading characteristics of a server {resource_provider/my_id/servers/some_server {read{some attribute}}

cloning a server {resource_provider/my_id/servers/some_server {update{resource_provider/my_id/servers/some_other_server}}

stopping / starting a server {resource_provider/my_id/servers/some_server {update{state attribute}}

list all servers (or servers with a specific attribute such as running) {resource_provider/my_id/servers {read{{...}}

The same seems to be generally true with other resources (i.e. storage, networks, servers etc).

Just my thoughts, I'd define a range of nouns for common resources, a limited set of verbs for actions and a range of attributes to describe common characteristics.

Feel free to ignore me if I've missed the point.

-- Simon Wardley Software Services Manager, Canonical Ltd. TEL: +44 (0)207 630 2451 MOB : +44 (0)7972 911 449 TWITTER: http://www.twitter.com/swardley/

_______________________________________________ occi-wg mailing list occi-wg@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@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.

Hello, In subject "Re: [occi-wg] Nouns and Verbs (was: Syntax of OCCI API)", Simon Wardley <simon.wardley@canonical.com> wrote:

...

{noun{verb{attribute}}} vector +1 for this.

This structure seems more like triples (subject, predicate, and object) rather than key/value pairs. I don't mean any specific format like RDF/XML or semantic kind of stuff. Just thought that noun/verb/attribute vector may match with triples in the conceptual level, where an attribute could be another noun (subject) for describing another resource. Best Regards, Taka -- Takahide MATSUTSUKA <Takahide.Matsutsuka@uk.fujitsu.com>, PMP Principal Researcher, Fujitsu Laboratories of Europe Limited Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE U.K. Tel: +44(0)20 8606 4676, COINS: 79541-4676

On Fri, Apr 17, 2009 at 2:07 PM, Richard Davies < richard.davies@elastichosts.com> wrote:

...

storage:

Tackling storage alone next, aside from CRUD, I believe the core verbs are:

- resize (might or might not be via updating the size attribute, as per other discussions this morning)

I don't have a problem so much with this being an update... ditto for memory, cores etc. as if there's an obvious problem you'll return an error (and it is, after all, idempotent). Even if the actual filesystem, memory balloon driver, etc. takes a while to do it, you know straight away if the allocation is successful.

- read and write (to actually get data into and out of the storage from outside the cloud)

For this (extension) I think we need to at least support basic HTTP based transfers (bearing in mind resumable http requests<http://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal>are a bit of a work in progress<http://startupmeme.com/google-gears-lets-you-upload-youtube-videos-upto-1-gb/>), but that we should also provide for some innovation. For example I should be able to rsync the raw block device of a physical server to the cloud from cron, create a storage resource pointing at this now-existing file and switch to it in the case of a disaster. I've listed some other ideas in the wiki too. WebDAV for example has native support in systems like Windows and Mac OS X for some time now... being able to "mount" the cloud (without SMB/CIFS) and drag e.g. an ISO image onto it would be great for usability.

- image (to copy data between storage areas within the cloud)

This gets interesting - it's something I was coming up against with cush<http://code.google.com/p/cush/>last year... how do you tell a server that you want one URL to be copied to another, without sending the contents of that URL (which could be many gigabytes) via the client (which could be a 3G iPhone). Things are easier if everything's a URL because you can just create the resource and let the infrastructure take care of retrieving and caching it locally... but the semantics still needs to make sense.

The other operations are all interesting, but secondary (I assume the point of taking storage offline would be that it is billed at a lower rate?)

...

*- start (aka online) *- stop (aka offline) *- snapshot? *- backup?

Thinking about the various current clouds, snapshots are probably the most common of these three. The snapshot operation will presumably create a new storage object, snapshotted from the first at the point of creation (likely copy on write).

Sure, snapshot's easy... you just have a "snapshot" actuator which returns a new resource (complete with a pointer to the "live" version).

This snapshot operation could be either a verb in itself, or alternatively that you pass the 'parent' to snapshot into the create call when you make the new storage object.

Interesting idea. To me a snapshot is something you do to an existing device. So is a "copy". Sam

On Fri, Apr 17, 2009 at 2:39 PM, Chris Webb <chris.webb@elastichosts.com>wrote:

Sam Johnston <samj@samj.net> writes:

...

For example I should be able to rsync the raw block device of a physical server to the cloud

Off-topic: rsyncing giant files/block devices does reduce network traffic, but it involves an end-to-end read at both ends as well as any writes. The thing which is most painfully constrained for cloud infrastructure providers is disk IO, especially with traditional hard drives with long seek times, so we're unlikely to provide such an interface for fear of encouraging its use!

rsyncing the contents of filesystems within block devices is far, far more friendly to shared storage, because by default files are skipped completely on the basis of size and mtime.

Interesting (albeit off topic)... a very long time ago I went for a [suite of] interviews at Google for a Senior SRE position. One of the questions was about distributing updates for a large site to a bunch of servers. I was chuffed becuase I knew all about rsync (actually I've met Andrew Tridgell - a fellow Aussie - a handful of times, read the paper, used Samba since it was born, etc.), so I said I'd do a recursive copy of the site using hardlinks, rsync to that copy and update a symlink to the root. This guy had obviously planned to talk about it for the full 40 minutes becase he proceeded to tell me I was wrong, that I should in fact be rsyncing the block device, and then wanted to talk about specifics of how the protocol worked. Serves me right for not reeling the answer out slowly :P Moral of the story: this is the kind of place providers will (safely) innovate and differentiate... we need to let them.

Sure, snapshot's easy... you just have a "snapshot" actuator which returns a

...

new resource (complete with a pointer to the "live" version).

Snapshots are easy if we're starting from scratch and are allowed to define their semantics, for instance a snapshot operation on a drive gives a new drive with copy-on-write behaviour between them.

The problem comes when you want to retrofit this to (say) Amazon EBS, where snapshots are second class objects, which can be generated from and imaged to a block device, but are not a block device in themselves.

If, on the other hand, you treat snapshots as a distinct type of object, functionality is lost from the interfaces of people who currently implement them better, so they do appear exactly like on-demand clones of drives.

True, but easily fixed by tracking a state and having e.g. a "mount" actuator. Sam

Richard, All the attributes you can give to a non-virtualized network should be available to the private virtualized network. For instance I might want to use DHCP to allocate addresses on a VM attached to it. Others might need a fixed IP address. Chuck Richard Davies wrote:

...

network: *- start (aka up) *- stop (aka down) others?

Finally to networking!

There are two points here:

1) Customers need to be able to purchase static IP addresses on the public internet. All existing clouds provide this (Amazon Elastic IP, etc) in addition to dynamic IP, and it is essential for webhosting, etc.

So, we need a noun for a static IP address on the public internet which the customer owns.

When the customer configures a server, then can then bind this static IP address onto one of their server's NICs - the static IP itself doesn't need any verbs.

2) As I understand the 'network' objects which Sam was proposing, these were actually specifiers for different virtual ethernet networks into which servers' NICs can be 'plugged' - one would be the internet, one would be the a 'private network' between a customer's servers, etc.

The minimal implementation here is that the 'network' objects are simply an identifier with no verbs and no attributes. If you link several servers to the same 'network' then behaviour is as if they are all plugged into a plain ethernet switch. No additional services (such as DHCP) are provided by the network, so the servers need to either: (a) have static IP addresses configured in their operating systems (b) all invent their own private IPs, as Windows does (c) one of the servers can run a DHCP server tself for the rest (d) in each server's configuration, we can specify an IP address which the cloud manager can DHCP to that individual server

The current API design is heading a different route, in which the 'network' object provides services to the servers plugged into it (e.g. a central DHCP service in the API example, or bridging to a physical Cisco VLAN). I'm wary about this, since it brings a whole world of networking configuration into our cloud API (see 'man dhcpd.conf' to see how complicated full configuration of just a DHCP server can become!).

Perhaps all services (and associated attributes and verbs) on the virtual networks are best considered optional as extensions?

Richard. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

Lars Larsson <larsson@cs.umu.se> writes:

Indeed. However, I think that such matters can be easily solved if we maintain a strict "infrastructure provider" approach to the problem:

+1 I'm very worried that if our scope isn't very tightly constrained, this whole discussion will end up trying to produce an API to every ISP service imaginable. An urge to bloat is already clear in many places. Cheers, Chris.

Keeping the analogy of renting physical infrastructure in mind, I think it is completely sufficient to expose operations in the API for defining network membership (which clearly sets up virtual networks between VMs) and static IP addresses or "acquire via DHCP" for the actual interfaces. This is like specifying which cables to connect to which interface, which is a pure infrastructure-related issue.

This is very much where I was heading - all we need is identifiers for the virtual networks ('red', 'blue'), etc, not any verbs or configuration of these themselves.

VM1: eth0 connected to "blue" network, static IP 192.168.0.1 eth1 connected to "red" network, DHCP

VM2: eth0 connected to "blue" network, DHCP

VM3: eth0 connected to "red" network, static IP 123.123.123.123

Note that the static IPs and DHCP are configuration of the servers' network interfaces, not of the network itself. The _only_ reference to the network itself is the identifier "red" or "blue" - so it needs only a noun, not any verbs or attributes. 'Active' networks with actual behaviours in the network object (e.g. a DHCP server in the network, attributes to configure that server, verbs to control the server) might also be possible as vendor extensions, but aren't the base case. Richard.