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.