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

Tue Apr 21 04:17:25 CDT 2009

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 at 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 at samj.net]
>> Sent: 17 April 2009 10:45
>> To: Edmonds, AndrewX
>> Cc: Andre Merzky; Chris Webb; occi-wg at 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 at intel.com>
>> Date: Fri, Apr 17, 2009 at 11:10 AM
>> Subject: Re: [occi-wg] Syntax of OCCI API
>> To: Andre Merzky <andre at merzky.net>, Chris Webb <
>> chris.webb at elastichosts.com>
>> Cc: "occi-wg at ogf.org" <occi-wg at 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 at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf
>> Of Andre Merzky
>> Sent: 17 April 2009 10:03
>> To: Chris Webb
>> Cc: occi-wg at 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 at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>>
>
> --
> Alexander Papaspyrou
> alexander.papaspyrou at tu-dortmund.de
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090421/d9b76d3c/attachment.html 