[occi-wg] Nouns and Verbs (was: Syntax of OCCI API)

[Thijs Metsch]

+1 That would be great :-)

On Fri, 2009-04-17 at 12:47 +0100, Alexis Richardson wrote:
> 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 at 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 at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf Of Simon Wardley
> > Sent: 17 April 2009 12:18
> > To: Sam Johnston
> > Cc: occi-wg at 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 at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> > -------------------------------------------------------------
> > Intel Ireland Limited (Branch)
> > Collinstown Industrial Park, Leixlip, County Kildare, Ireland
> > Registered Number: E902934
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
> > _______________________________________________
> > occi-wg mailing list
> > occi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/occi-wg
> >
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
-- 
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 at sun.com
D-93049 Regensburg                  http://www.sun.com