January 2010 - occi-wg - lists.ogf.org

OCCI guide
by Edmonds, AndrewX 09 Feb '10

09 Feb '10

I've began a document with on how OCCI can be implemented from the specification. It includes the basic on-the-wire examples which provide the means for the management lifecycle of resources governed by an OCCI compliant service manager. It is of course open for comment, criticism etc. https://docs.google.com/Doc?docid=0AS0AExvzzYt7YWQ2enFodmt6czlfMzRnM25mMnJm… Andy ------------------------------------------------------------- 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.

3 3

Delta-cloud Driver for OCCI on OpenNebula
by Ignacio Martin Llorente 29 Jan '10

29 Jan '10

More at http://deltacloud.org/drivers.html#launch_the_server_opennebula -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org OpenNebula Open Source Toolkit for Cloud Computing: http://www.OpenNebula.org RESERVOIR European Project in Cloud Computing: http://www.reservoir-fp7.eu

3 2

Telefonica I+D using OCCI in its open source service manager
by Ignacio Martin Llorente 28 Jan '10

28 Jan '10

More details: http://claudia.morfeo-project.org/ -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org OpenNebula Open Source Toolkit for Cloud Computing: http://www.OpenNebula.org RESERVOIR European Project in Cloud Computing: http://www.reservoir-fp7.eu

4 4

Reminder: concall in 30 minutes
by Thijs Metsch 27 Jan '10

27 Jan '10

Hi, A short reminder of the weekly concall which will start in 30 min... Dial-in details can be found here: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… Cheers, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

Categorization via link relations
by Mike Kelly 21 Jan '10

21 Jan '10

I really like the protocol, you've done a great job I have a question: Why is Category given a unique header, and not simply treated as another type of link relation for a resource? i.e. Category: compute; scheme="http://purl.org/occi/kind/"; label="Compute Resource" .. could that actually be written as: Link: <http://occi.org/kinds/compute>; rel=<http://purl.org/occi/kind>; title="Compute Resource" Cheers, Mike

2 4

OVF MIME type
by Sam Johnston 21 Jan '10

21 Jan '10

Thijs, As our liaison with DMTF, can you please formally request that they allocate a MIME type to the format (assuming they have not already done so). It's not really our job and I'm not sure how a request from us to IANA would be handled (if at all), Thanks, Sam

2 2

Fwd: Categorization via link relations
by Sam Johnston 21 Jan '10

21 Jan '10

Morning all, The following off-list discussion ought to shed some light on the relationship between metadata (properties, categories, links) and representations... hopefully it will answer more questions than is raises! Sam ---------- Forwarded message ---------- From: Lori Mac Vittie <L.MacVittie(a)f5.com> Date: Thu, Jan 21, 2010 at 11:46 AM Subject: RE: [occi-wg] Categorization via link relations To: Sam Johnston <samj(a)samj.net> Not at all, you’re right – it would be very helpful. Lori *From:* Sam Johnston [mailto:samj@samj.net] *Sent:* Thursday, January 21, 2010 8:45 AM *To:* Lori Mac Vittie *Subject:* Re: [occi-wg] Categorization via link relations Lori, Forgot to ask - this explanation would be very useful to others - do you mind if I copy it to the list? Sam On Thu, Jan 21, 2010 at 11:12 AM, Sam Johnston <samj(a)samj.net> wrote: On Thu, Jan 21, 2010 at 9:05 AM, Lori Mac Vittie <L.MacVittie(a)f5.com> wrote: Sam, I’ve been digging in a bit deeper into the OCCI spec as it sits and was wondering what you think is the proper mechanism for extending the “network” resource to include more infrastructure concepts. So there are basically two ways: in-band and out-of-band. That is, you can define your own representation identified by MIME type - this is what we do with OVF. Or you can create properties/categories/links (e.g. compute.cores) For example, a large class of network resources can be classified as a “proxy” (either transparent or inline). Proxies include the notion of network as they’re currently defined, so I was thinking given your current nomenclature it would be “occi.network.proxy”. “Proxy” would need to encapsulate a type, probably an ENUM representing one of “firewall, loadbalancer, cache” etc… There are quite a few in this category as almost every piece of infrastructure can technically be classified as some sort of proxy. I would use a category for this - perhaps a global "device type" category which could be router, switch, proxy, load balancer, etc. (and of course multiple values would be allowed). The actual configuration itself - say a squid config file - would either be linked (as it essentially describes the resource... could use the existing "describedby" relation or create a new one) or could be an actual representation (e.g. you could GET the resource directly in application/vnd.squid-conf or similar). What I’m having trouble with is that it would make sense to reuse the “network” definition down the hierarchy because every “proxy” has associated with it multiple “networks” (usually). At a minimum you’re usually defining at least one “management network” and in the case of an inline configuration one “public network” (the one which is the actual endpoint for the service provided. Any resource can have LINKs to other resources so arbitrarily complex networks can be modelled easily. I am unclear whether it would make sense to define “occi.network.proxy.firewall” or to leave the “type” as an attribute of “occi.network.proxy”. What is the process you use to decide? I’m also not entirely certain that “proxy” is the right noun, but it **feels** right as it’s a broad description (and accurate abstraction) of the entire class of devices. Where you have the urge to use an enum you probably want to consider categories. For example you could request all load balancers in the US east coast with a request like "GET /-/us-east/loadbalancer". Sam *From:* occi-wg-bounces(a)ogf.org [mailto:occi-wg-bounces@ogf.org] *On Behalf Of *Sam Johnston *Sent:* Wednesday, January 20, 2010 7:31 AM *To:* Mike Kelly *Cc:* occi-wg(a)ogf.org *Subject:* Re: [occi-wg] Categorization via link relations Mike, This was mentioned on the call today (during which I was unable to speak despite calling in twice - presumably something at my end) and I definitely agree with Alexis in that we shouldn't create new technology where we don't absolutely have to. I wrote the Web Categories<http://tools.ietf.org/html/draft-johnston-http-category-header-00>Internet-Draft for OCCI because there didn't appear to be any existing mechanism for this, but eventually came to the realisation (like you) that it would be possible to convey this information via the Link: header. What's possible and what's sensible aren't always the same thing though and I'd argue that there's not much difference in terms of handling effort as you'll most likely be dealing with raw headers anyway (remember we need schemes so even if there was some intelligence to the handling of links we'd have to bypass it for this). A greater concern for me is the handling of properties/attributes. Rather than give people carte blanche in terms of encouraging them to mint their own headers for each additional property, I think it makes a lot more sense to have e.g. a "Property" header which acts like a kind of server-side cookie (and is modelled after Set-Cookie[2]). This is what is currently documented and all the examples I've thrown at it all work nicely thus far. Sam On Sat, Jan 16, 2010 at 8:53 AM, Mike Kelly <mike(a)mykanjo.co.uk> wrote: Hi Sam, A reason for sticking to Link headers could be to keep 'consistency' in the protocol's hypertext mechanisms? Another reason is that tools for handling Link headers, client and server side, are likely to have broader availability. Cheers, Mike Sam Johnston wrote: Mike, Thanks for taking the time to look at our specifications. The categories are dealt with in a separate IETF Internet-Draft ( http://tools.ietf.org/html/draft-johnston-http-category-header-00) but it's true that they could be layered on top of the Link: header. I hadn't considered this option at the time but it does make some sense. OTOH we need to sensibly layer properties/attributes on top of HTTP headers so we'll probably be blazing our own trail there anyway (using Property:/Attribute: headers modelled after Set-Cookie[2]:). Sam On Fri, Jan 8, 2010 at 8:23 PM, Mike Kelly <mike(a)mykanjo.co.uk <mailto: mike(a)mykanjo.co.uk>> wrote: I really like the protocol, you've done a great job I have a question: Why is Category given a unique header, and not simply treated as another type of link relation for a resource? i.e. Category: compute; scheme="http://purl.org/occi/kind/"; label="Compute Resource" .. could that actually be written as: Link: <http://occi.org/kinds/compute>; rel=<http://purl.org/occi/kind>; title="Compute Resource" Cheers, Mike _______________________________________________ occi-wg mailing list occi-wg(a)ogf.org <mailto:occi-wg@ogf.org> http://www.ogf.org/mailman/listinfo/occi-wg

1 0

Fwd: Fwd: New Version Notification - draft-nottingham-http-link-header-07.txt
by Mike Kelly 21 Jan '10

21 Jan '10

Just in case anyone missed this - there's a new version of link header draft: http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.txt Cheers, Mike Mark Nottingham wrote: > Begin forwarded message: > > >> From: Internet-Draft(a)ietf.org >> Date: 19 January 2010 4:30:02 PM AEDT >> To: mnot(a)pobox.com, draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com >> Subject: New Version Notification - draft-nottingham-http-link-header-07.txt >> >> New version (-07) has been submitted for draft-nottingham-http-link-header-07.txt. >> http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.txt >> Sub state has been changed to AD Follow up from New Id Needed >> >> Diff from previous version: >> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-link-header-07 >> >> IETF Secretariat. >> > > > -- > Mark Nottingham http://www.mnot.net/ > > >

1 0

teleconf
by Xiaoyu Chen 20 Jan '10

20 Jan '10

Dear all: Sorry about having missed the group teleconf today. For one reason I was in another teleconf meeting with JISC. Secondly I was so stupid having mixed the CET and GMT time. I wonder whether you guys got chances to have a discussion on the arrangement next OGF OCCI sessions. Would it possible to have a special session to be setup for TeciRes project ? Best Regards! X. Chen -------- LSL Electronics and Computer Science University of Southampton SO17 1BJ United Kingdom [cid:image002.jpg@01CA99EE.95E83610] +44 238 0591 523

1 0

Reminder: Weekly Conference call today!
by Thijs Metsch 20 Jan '10

20 Jan '10

Short reminder that we'll have our first concall of the year later on today... Looking forward speaking to you all later, -Thijs -------- Forwarded Message -------- > From: Thijs Metsch <Thijs.Metsch(a)Sun.COM> > To: occi-wg <occi-wg(a)ogf.org> > Subject: [occi-wg] Weekly Conference call > Date: Mon, 18 Jan 2010 10:30:49 +0100 > > Hi @all, > > The outcome of the doodle stated that the following time would be best > suited for our weekly conference calls (Sorry Andre): > > Wednesdays 10am EDT, 4pm CET, 3pm BST, Thursday 12am Tokyo > > The bridge information hasn't changed and can be found here: > > http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… > > The Agenda for the first confcall is pretty long so hopefully it'll fit > in one hour: > > * Roadmap > * Extensions to the current doc series > * Integration/Interoperability testing > * Adoption of OCCI > * Intergration of other standards > > Thanks, > > -Thijs > > -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds http://www.twitter.com/befreax Software Engineer Cloud, Grid and Virtualization Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0