+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@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
_______________________________________________ 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