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