[occi-wg] confusion about status of link / headers

Tue Oct 20 05:44:31 CDT 2009

I think what Sam is proposing is the following:

1) If OCCI can handle 'any' data representation, eg OVF, XML, JSON,
then it needs some core / common model.  Otherwise: there can be no
defined behaviour / interop

2) This core / common model is ALL metadata

3) ALL this metadata should be in the headers

4) ALL the non core stuff eg OVF payload, XML representation, should be in body

Sam - is that right?

a

On Tue, Oct 20, 2009 at 11:39 AM, Sam Johnston <samj at samj.net> wrote:
> 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 (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.
>
>