[occi-wg] confusion about status of link / headers
Sam Johnston
samj at samj.net
Tue Oct 20 05:39:32 CDT 2009
On Tue, Oct 20, 2009 at 12:28 PM, Edmonds, AndrewX <
andrewx.edmonds at intel.com> wrote:
> To that point I'd ask - If we're talking about meta-data that infers there
> is some data to accompany it. Where are the examples of this data? This
> would help in forming the full picture.
>
Here, from the core spec
<http://occi.googlecode.com/hg/docs/occi-core.html>(using OVF as an
example, but could be anything). Request is
green, response metadata is yellow & response data/payload is orange:
> GET /us-east/webapp/vm01 HTTP/1.1
> User-Agent: occi-client/1.0 (linux) libcurl/7.19.4 OCCI/1.0
> Host: cloud.example.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sat, 10 Oct 2009 12:56:51 GMT
< Content-Type: application/ovf
< Link: </us-east/webapp/vm01;start>;
< rel="http://purl.org/occi/action/start";
< title="Start"
< Link: </us-east/webapp/build.pdf>;
< rel="related";
< title="Documentation";
< type="application/pdf"
< Category: compute;
< label="Compute Resource";
< scheme="http://purl.org/occi/kind/"
< Server: occi-server/1.0 (linux) OCCI/1.0
< Connection: close
<
< <?xml version="1.0" encoding="UTF-8"?>
< <Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
< xmlns:ovf="http://schemas.dmtf.org/ovf/envelope/1"
< xmlns="http://schemas.dmtf.org/ovf/envelope/1"
< xml:lang="en-US">
...
> -----Original Message-----
> From: occi-wg-bounces at ogf.org [mailto:occi-wg-bounces at ogf.org] On Behalf
> Of Alexis Richardson
> Sent: 20 October 2009 09:49
> To: Sam Johnston
> Cc: Tim Bray; occi-wg at ogf.org
> Subject: Re: [occi-wg] confusion about status of link / headers
>
> Sam,
>
> Please don't throw around words like "bunk" willy nilly.
>
> I have just had a look at
> http://www.rackspacecloud.com/cloud_hosting_products/servers/api
>
> I can see some limited use of headers for metadata in a few places.
> That's never been controversial. But the understanding that I have of
> your proposal is to use headers wholesale for all metadata. Rackspace
> don't appear to do that, unless I have misunderstood their document.
> I also may have misunderstood your proposal. If nobody understands
> your proposal except you, then it will not be possible to gain
> consensus around it.
>
> Are you saying "OCCI metadata should be more like Rackspace metadata"?
>
> alexis
>
>
> On Tue, Oct 20, 2009 at 9:07 AM, Sam Johnston <samj at samj.net> wrote:
> > On Tue, Oct 20, 2009 at 9:55 AM, Alexis Richardson
> > <alexis.richardson at gmail.com> wrote:
> >>
> >> What about compute clouds?
> >
> > Rackspace Cloud API for a start:
> >
> >> HTTP/1.1 204 No Content
> >> Date: Mon, 12 Nov 2007 15:32:21 GMT
> >> Server: Apache
> >> X-Server-Management-Url:
> https://servers.api.rackspacecloud.com/v1.0/35428
> >> X-Storage-Url: https://storage.clouddrive.com/v1/CloudFS_9c83b-5ed4
> >> X-CDN-Management-Url: https://cdn.clouddrive.com/v1/CloudFS_9c83b-5ed4
> >> X-Auth-Token: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb
> >> Content-Length: 0
> >> Content-Type: text/plain; charset=UTF-8
> >
> >
> > Microsoft Azure uses headers for "attributes" as well, in the same way as
> I
> > had originally proposed:
> >
> > x-ms-meta-name: value Returns a metadata value for the container.
> >
> > However prefer that the header names are static/opaque rather than using
> a
> > template and parsing them:
> >
> >> Attribute: name=value
> >
> > This to me is cleaner and more self-explanatory, plus it is easily
> collapsed
> > ala:
> >
> >> Attribute: name1=value1, name2=value2, ... namen=valuen
> >
> > Anyway suffice to say that claims this is somehow "experimental" are
> bunk.
> >
> > Sam
> >
> >> On Tue, Oct 20, 2009 at 6:19 AM, Adrian Cole <adrian at jclouds.org>
> wrote:
> >> > Here are options for metadata used in some of the major storage clouds
> >> > FWIW:
> >> >
> >> > S3, Rackspace, EMC Atmos, Azure - Headers
> >> > Nirvanix - query params in, xml entity out
> >> > Mezeo - entity
> >> >
> >> > Of the ones using headers, S3, Rackspace and Azure use prefix with
> >> > values stored as-us. Atmos joins all metadata together into one
> >> > header, making parsing trivial (split /,/), but necessary.
> >> >
> >> > The most expensive option of the above is entity, where each metadata
> >> > value is a separate GET. However, entities allow binary metadata and
> >> > zero restrictions on it, which may be useful.
> >> >
> >> > In jclouds, we time parsing of response values. A simple XML doc with
> >> > only several elements written in SAX takes a few ms to parse. My log
> >> > files are not precise enough to find the overhead in parsing headers:
> >> > they always start and finish within the same millisecond.
> >> >
> >> > I hope this background helps, and also helps explain why I'm vocal on
> >> > such topics such as headers vs entities :)
> >> >
> >> > Cheers,
> >> > -Adrian
> >> >
> >> >
> >> > On Mon, Oct 19, 2009 at 4:21 PM, Sam Johnston <samj at samj.net> wrote:
> >> >> On Tue, Oct 20, 2009 at 12:57 AM, gary mazzaferro
> >> >> <garymazzaferro at gmail.com>
> >> >> wrote:
> >> >>
> >> >>> The http header and key/value pairs need to parsed also, there is no
> >> >>> free
> >> >>> ride here.
> >> >>
> >> >> Every HTTP library I have ever used parses HTTP headers and puts them
> >> >> in a
> >> >> nice hash for you ready to consume. If we go for "Name: Value" then
> >> >> that's
> >> >> all there is to it. If we go for "Attribute: name=value" as is
> >> >> currently
> >> >> proposed (which is arguably cleaner, follows cookies' "prior art" and
> >> >> avoids
> >> >> Amazon's prefix hack) then you just have to split on '='.
> >> >>
> >> >> To illustrate how clean this is by example:
> >> >>
> >> >>> #!/usr/bin/python
> >> >>> import urllib2
> >> >>> response = urllib2.urlopen('http://cloud.example.com/myvm')
> >> >>> representation = response.read()
> >> >>> metadata = response.info()
> >> >>> print metadata['occi-compute-cores']
> >> >>
> >> >> As soon as you start talking about payloads you have to fire up a
> >> >> parser
> >> >> (JSON/XML/Atom/etc.) or write your own (previous text rendering)
> which
> >> >> is
> >> >> significantly more work to do at both design and run times. Not to
> >> >> mention
> >> >> more work for us to do now and more scope for interoperability
> >> >> problems.
> >> >>
> >> >> Sam
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> occi-wg mailing list
> >> >> occi-wg at ogf.org
> >> >> http://www.ogf.org/mailman/listinfo/occi-wg
> >> >>
> >> >>
> >> > _______________________________________________
> >> > occi-wg mailing list
> >> > occi-wg at ogf.org
> >> > http://www.ogf.org/mailman/listinfo/occi-wg
> >> >
> >
> >
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
> -------------------------------------------------------------
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20091020/a49f0522/attachment.html
More information about the occi-wg
mailing list