- occi-wg - lists.ogf.org

Google Groups: You've been invited to Cloud Demo
by noreply＠googlegroups.com 05 Feb '10

05 Feb '10

Mark macredcape(a)gmail.com has invited you to join the Cloud Demo group with this message: This is a Google group for folks that wish to work on the joint demo. Please join the list so that we can carry on the conversations without overly burdening the larger groups. Here is the group's description: Group of folks working toward a series of demos for cloud computing and storage featuring standards such as OCCI, CDMI and others TBD. ---------------------- Google Groups Information ---------------------- You can accept this invitation by clicking the following URL: http://groups.google.com/group/cloud-demo/sub?s=DGt-BwwAAAASxY0wGRR03krl6dm… --------------------- If This Message Is Unwanted --------------------- If you feel that this message is abuse, please inform the Google Groups staff by using the URL below. http://groups.google.com/groups/abuse?invite=YQAAABu4mtTPAAAAs_-g5dUAAACKu5…

1 0

Reminder: OCCI and Cloud Demo concall today...
by Thijs Metsch 03 Feb '10

03 Feb '10

Hi folks, The OCCI weekly concall is at 4pm CET, 7am PDT. Our conference bridge details can be found here: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… The Cloud demo concall will be at 5pm CET, 8am PDT. Mark will host that call: Call info: Teleconference: 866-545-5227 International: (215) 446-3648 Passcode: 6300276# Hope to talk to you later!, -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

Cloud Demo Planning
by Mark A. Carlson 02 Feb '10

02 Feb '10

OCCI folks, I'd like to start weekly meetings to plan joint demos between SDOs including cloud computing, security and storage. Please indicate if any of these times: http://doodle.com/wi6h4wkid67qcqch work for you on a weekly basis. Thanks, -- mark

1 1

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