October 2009 - occi-wg - lists.ogf.org

name-based access to resources
by Adrian Cole 21 Oct '09

21 Oct '09

Hello, WG. In re-reading the OCCI spec, something became clear to me I frankly hadn't noticed before: All operations require system-generated ids. POST creates an object and returns a url containing its UUID. All other operations require this UUID. UUIDs are important, and there will be systems that should use this for efficiency's sake. However, moderate use would pretty much require users to store a mapping between what they call a resource and its UUID. This mapping would end up as another table or cache that clients would need to maintain. The alternate path is a name-based interface to the system that allows access to resources based on ids the client decides. A good example of this is atmos online, where they have 2 interfaces: /objects and /namespace but offer the same methods on each. For convenience, namespace methods return the UUID in a response header, so one can later switch. Regardless, clients do not need to parse metadata or listings to access their resources as they are available by their natural names. Is this something we can consider supporting in OCCI? Regards, -Adrian jclouds

3 5

Link relations (was Re: confusion about status of link / headers)
by Sam Johnston 21 Oct '09

21 Oct '09

Michael, Thanks for the feedback. We certainly need to document all the actions we specify and will use a registry for that such that future functionality (I'll again use the example of being able to "teleport" a resource from one location to another) can be catered for. Regarding the "class" extension attribute on the link relations - its purpose is to group relations into different classes - e.g. actions vs pagination vs interfaces, etc. I used "class" because it's already specified elsewhere and its meaning is well understood - "type" on the other hand should be a content-type in which case type="action" would be illegal sfaict. I'll suggest "class" to Mark for possible inclusion in the Web Linking draft but regardless we can define our own extensions as we see fit (which is useful for things like local interface identifiers - e.g. "eth0" or "sda"). Sam On Wed, Oct 21, 2009 at 5:59 AM, Michael Behrens <michael.behrens(a)r2ad.com>wrote: > Sam, > I presume that interested clients would parse for the value of the "rel" > parameter in order to know the purpose of the link. If so, then I think > that all the life-cycle values should also be listed in table 2 - Link > Relations. I inserted the type="action" in the example below - I did not > see "class" as a link-parameter in the draft-nottingham draft on > web-linking. Also, I presume the title parameter would be optional. > > < Link: </us-east/webapp/vm01;start>;< rel="http://purl.org/occi/action/start"; > > type="action"< title="Start" > > > > > Good discussion on this thread!....looking forward to the telecons and the > future F2F (good idea Andre!). > > PS: We are going to be implementing a small portion of the spec soon - > initially will be coding up the GET verb. We'll share our experiences as > soon as we can. I'll be coding up the client - so it should be able to hit > our implementation and others too. > > > -- > Michael Behrens > >

1 0

Re: [occi-wg] confusion about status of link / headers
by Sam Johnston 20 Oct '09

20 Oct '09

Adrian, We don't vote... we discuss our way to consensus and escalate if we fail. Anyway I've had enough for one day/lifetime and I've got a house full of furniture to build tonight. I do wonder how many people here have actually bothered to read the spec and understand the issues though - if you haven't already then please do so now and speak up if anything doesn't make sense. Sent from my iPhone On 20/10/2009, at 18:44, Adrian Cole <adrian(a)jclouds.org> wrote: > As we aren't introducing new information, I think we are at a point > where a vote can take place. This issue isn't infinitely complex, and > reasonable to model in choices. OCCI desires to be a community > process, so let's see where we fall on this. > > Do you agree? > -Adrian > > On Tue, Oct 20, 2009 at 9:39 AM, Alexis Richardson > <alexis.richardson(a)gmail.com> wrote: >> Sam, >> >> On Tue, Oct 20, 2009 at 5:31 PM, Sam Johnston <samj(a)samj.net> wrote: >>> Alexis, >>> >>> Sweeping, unjustified statements are intensely frustrating, not to >>> mention unhelpful in the absence of a coherent alternative. If >>> people >>> choose not to disclose conflicts I happen to be aware of then you >>> bet >>> I'll disclose them for them - nothing personal about it. >> >> I don't know what 'conflicts' you are referring to, or how these >> relate to the matter at hand. If by 'sweeping, unjustified' you >> refer >> to the word 'unprecedented' then I shall justify it by pointing out >> that - at least as I currently understand it - you are proposing use >> of headers to a *greater* extent than has been done before and to >> cover a *greater* set of use cases. >> >> >>> Cutting to the chase, both Microsoft and Amazon are using headers >>> for >>> metadata to the same extent as what has been proposed. >> >> Really - to the "same" extent? That seems contrary to what has been >> asserted on this thread previously. >> >> >>> What premature optimisation? *Not* using XML? Do we really need to >>> drag that carcass out again? Surely Adrian's performance tests put >>> the >>> last nail in that particular coffin. >> >> Premature optimisation = making performance a critical design concern >> when we want an API. >> >> I have noted Adrian's points as have others. >> >> >>> The question really is about whether we want to be an interface/ >>> protocol like HTTP or some mongrel hybrid of that along with a set >>> of >>> XML, JSON and/or text formats for everything we ever intend to model >>> (knowing that work has already been done by others). >> >> Work that has been done by others and shown to work, is a good thing. >> >> alexis >> >> >> >> >>> Sent from my iPhone >>> >>> On 20/10/2009, at 18:10, Alexis Richardson >>> <alexis.richardson(a)gmail.com> wrote: >>> >>>> Sam >>>> >>>> Cut the personal stuff please. >>>> >>>> Re 'unproven', I think the issues people are having are: >>>> >>>> * The extent, scope and purpose of your application of headers to >>>> metadata is unprecedented - as I understand it. Nobody is saying >>>> it >>>> has not been done in other and restricted cases. >>>> >>>> * Premature optimisation. >>>> >>>> alexis >>>> >>>> >>>> >>>> On Tue, Oct 20, 2009 at 4:44 PM, Sam Johnston <samj(a)samj.net> >>>> wrote: >>>>> Gary, >>>>> >>>>> Please be specific with your objections so as I can have some >>>>> hope of >>>>> answering them... "several other emails" does not suffice as to >>>>> the >>>>> best of my knowledge there are no outstanding issues that I have >>>>> not >>>>> comprehensively and convincingly dealt with. >>>>> >>>>> Your repeated assertions than HTTP headers are... what is it >>>>> now... >>>>> "unproven"... are demonstrably unfounded (refer to the various >>>>> cloud >>>>> APIs referred to by myself and Adrian, including both MS Azure and >>>>> Amazon S3, as well as the history of the Internet in general) and >>>>> given the frequency, bordering on FUD. >>>>> >>>>> Regarding performance, OCCI should strive to be as efficient as >>>>> possible as it primarily targets public cloud providers who >>>>> operate >>>>> at >>>>> arbitrarily large "cloud" scale. The existing specification is >>>>> *extremely* efficient and alternatives would at least want to be >>>>> in >>>>> the same neighbourhood. Efficiency may be an inconvenient factor >>>>> for >>>>> whatever your alternative is, but it's critical for many of our >>>>> use >>>>> cases. >>>>> >>>>> Finally, you reject OVF without providing any alternative beyond >>>>> building a replacement from scratch ourselves, after our second >>>>> and >>>>> final deadline has just sailed by no less. Have you considered the >>>>> implementation cost of this? And in the same breath you accuse my >>>>> proposal of being "unproven"? Give me a break... >>>>> >>>>> Correct me if I'm wrong but the way I see it is that you want to >>>>> revert the last 2-3 months of my work because you have an >>>>> investment >>>>> in an old version of the spec. With each day I spend on OCCI >>>>> costing >>>>> me well over €1,000 excuse me for being pissed about someon >>>>> e with >>>>> such a blatantly obvious conflict attacking my work and refusing >>>>> to >>>>> provide a coherent argument, particularly with no "camera ready" >>>>> alternative anywhere in sight. >>>>> >>>>> Sent from my iPhone >>>>> >>>>> On 20/10/2009, at 16:51, Gary Mazz <garymazzaferro(a)gmail.com> >>>>> wrote: >>>>> >>>>>> I've understood Sam's proposal from the beginning. I have had >>>>>> issue >>>>>> with from the beginning. >>>>>> >>>>>> Although I find it very interesting and valuable in terms of >>>>>> economy, I have issue with it as the OCCI's primary interface >>>>>> implementation for a few reasons which have been outlined in >>>>>> several >>>>>> other emails. >>>>>> >>>>>> It appears that Sam has created a new technology, a lower cost >>>>>> RPC >>>>>> mechanism, which is unproven for both small and wide scale >>>>>> deployment. For interoperability, IMO, occi should focus on >>>>>> proven >>>>>> mainstream technologies as the primary interfaces. I am not >>>>>> suggesting, shelving or not supporting Sam's proposal, based on >>>>>> market acceptance, it may prove to be one of many occi interface >>>>>> implementations. >>>>>> >>>>>> As for cost saving in interface technologies, I do not buy into >>>>>> the >>>>>> idea that the occi traffic will be so overwhelming that there >>>>>> is a >>>>>> requirement to maximally optimize http requests and responses. >>>>>> IMO, >>>>>> in comparison to images and consumer data occi traffic will be >>>>>> insignificant. I think we are worrying about spilled milk while >>>>>> the >>>>>> house is burning. >>>>>> >>>>>> There has been some discussion on supporting technologies >>>>>> including >>>>>> OVF. Whether occi supports OVF has not been fully discussed, >>>>>> examined or any consensus reached. I believe adopting >>>>>> technologies >>>>>> like OVF will only lead to mapping issues between occi attributes >>>>>> and the external formats creating a long term management >>>>>> headache. >>>>>> >>>>>> cheers, >>>>>> gary >>>>>> >>>>>> >>>>>> Alexis Richardson wrote: >>>>>>> OK >>>>>>> >>>>>>> Is Sam's statement something that we can achieve consensus >>>>>>> around? >>>>>>> >>>>>>> a >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 20, 2009 at 12:47 PM, Sam Johnston <samj(a)samj.net> >>>>>>> wrote: >>>>>>> >>>>>>>> Alexis, >>>>>>>> >>>>>>>> Seems our posts crossed in the mail. I hope the last one clears >>>>>>>> things up >>>>>>>> but the fact that you're using OVF and XML/JSON interchangeably >>>>>>>> suggests >>>>>>>> that you [are possibly one of many who] don't grok the >>>>>>>> proposal. >>>>>>>> Worse, it >>>>>>>> seems you've got it back to front in thinking of the "core" as >>>>>>>> metadata, >>>>>>>> which is not at all what I had intended. >>>>>>>> >>>>>>>> The focus is on the resources and their various >>>>>>>> representations. >>>>>>>> The >>>>>>>> metadata (that is, data about data) essentially provides >>>>>>>> whatever is >>>>>>>> necessary to "glue" these resources together. It is basically >>>>>>>> using HTTP as >>>>>>>> the meta-model rather than an envelope format like Atom/SOAP >>>>>>>> or, >>>>>>>> worse, a >>>>>>>> meta-model that we have to create ourselves from scratch. >>>>>>>> >>>>>>>> So it's more like: >>>>>>>> >>>>>>>> 1) OCCI is compatible with ALL existing formats, eg OVF >>>>>>>> >>>>>>>> 2) Existing formats are used are used for ALL representations >>>>>>>> >>>>>>>> 3) ALL additional metadata should be in the headers >>>>>>>> >>>>>>>> 4) ALL of the core stuff should be in the body (that is, the >>>>>>>> metadata in the >>>>>>>> headers is just there to support the data and wire it up in >>>>>>>> useful >>>>>>>> ways) >>>>>>>> >>>>>>>> I think the confusion stems from your assuming that there is >>>>>>>> still >>>>>>>> XML/JSON/Atom/etc. representations. There aren't. HTTP headers >>>>>>>> provide a >>>>>>>> single, performant, interoperable metadata channel that has >>>>>>>> already been >>>>>>>> both standardised and extensively implemented. >>>>>>>> >>>>>>>> If you've followed me this far then you should have realised >>>>>>>> that >>>>>>>> every HTTP >>>>>>>> user agent (e.g. Perl's LWP, Python's urllib2, C's libcurl, >>>>>>>> etc.) >>>>>>>> is already >>>>>>>> a basic OCCI client out-of-the-box. The result is that 5-line >>>>>>>> scripts like >>>>>>>> demo.py are functional with no dependence on client libraries >>>>>>>> (that would >>>>>>>> absolutely be necessary if you were to start trying to define >>>>>>>> your >>>>>>>> own >>>>>>>> formats). >>>>>>>> >>>>>>>> Sam >>>>>>>> >>>>>>>> PS I'm sorry my "bunk" comment came across as referring to you >>>>>>>> personally - >>>>>>>> it was directed at the argument. >>>>>>>> >>>>>>>> On Tue, Oct 20, 2009 at 12:44 PM, Alexis Richardson >>>>>>>> <alexis.richardson(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> 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(a)samj.net> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On Tue, Oct 20, 2009 at 12:28 PM, Edmonds, AndrewX >>>>>>>>>> <andrewx.edmonds(a)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(a)ogf.org [mailto:occi-wg- >>>>>>>>>>> bounces(a)ogf.org] On >>>>>>>>>>> Behalf >>>>>>>>>>> Of Alexis Richardson >>>>>>>>>>> Sent: 20 October 2009 09:49 >>>>>>>>>>> To: Sam Johnston >>>>>>>>>>> Cc: Tim Bray; occi-wg(a)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(a)samj.net> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 20, 2009 at 9:55 AM, Alexis Richardson >>>>>>>>>>>> <alexis.richardson(a)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(a)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(a)samj.net> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Tue, Oct 20, 2009 at 12:57 AM, gary mazzaferro >>>>>>>>>>>>>>> <garymazzaferro(a)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(a)ogf.org >>>>>>>>>>>>>>> http://www.ogf.org/mailman/listinfo/occi-wg >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> occi-wg mailing list >>>>>>>>>>>>>> occi-wg(a)ogf.org >>>>>>>>>>>>>> http://www.ogf.org/mailman/listinfo/occi-wg >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> occi-wg mailing list >>>>>>>>>>> occi-wg(a)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. >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> occi-wg mailing list >>>>>>> occi-wg(a)ogf.org >>>>>>> http://www.ogf.org/mailman/listinfo/occi-wg >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> _______________________________________________ >> occi-wg mailing list >> occi-wg(a)ogf.org >> http://www.ogf.org/mailman/listinfo/occi-wg >>

4 3

Re: [occi-wg] confusion about status of link / headers
by Sam Johnston 20 Oct '09

20 Oct '09

Alexis, Sweeping, unjustified statements are intensely frustrating, not to mention unhelpful in the absence of a coherent alternative. If people choose not to disclose conflicts I happen to be aware of then you bet I'll disclose them for them - nothing personal about it. Cutting to the chase, both Microsoft and Amazon are using headers for metadata to the same extent as what has been proposed. What premature optimisation? *Not* using XML? Do we really need to drag that carcass out again? Surely Adrian's performance tests put the last nail in that particular coffin. The question really is about whether we want to be an interface/ protocol like HTTP or some mongrel hybrid of that along with a set of XML, JSON and/or text formats for everything we ever intend to model (knowing that work has already been done by others). Sent from my iPhone On 20/10/2009, at 18:10, Alexis Richardson <alexis.richardson(a)gmail.com> wrote: > Sam > > Cut the personal stuff please. > > Re 'unproven', I think the issues people are having are: > > * The extent, scope and purpose of your application of headers to > metadata is unprecedented - as I understand it. Nobody is saying it > has not been done in other and restricted cases. > > * Premature optimisation. > > alexis > > > > On Tue, Oct 20, 2009 at 4:44 PM, Sam Johnston <samj(a)samj.net> wrote: >> Gary, >> >> Please be specific with your objections so as I can have some hope of >> answering them... "several other emails" does not suffice as to the >> best of my knowledge there are no outstanding issues that I have not >> comprehensively and convincingly dealt with. >> >> Your repeated assertions than HTTP headers are... what is it now... >> "unproven"... are demonstrably unfounded (refer to the various cloud >> APIs referred to by myself and Adrian, including both MS Azure and >> Amazon S3, as well as the history of the Internet in general) and >> given the frequency, bordering on FUD. >> >> Regarding performance, OCCI should strive to be as efficient as >> possible as it primarily targets public cloud providers who operate >> at >> arbitrarily large "cloud" scale. The existing specification is >> *extremely* efficient and alternatives would at least want to be in >> the same neighbourhood. Efficiency may be an inconvenient factor for >> whatever your alternative is, but it's critical for many of our use >> cases. >> >> Finally, you reject OVF without providing any alternative beyond >> building a replacement from scratch ourselves, after our second and >> final deadline has just sailed by no less. Have you considered the >> implementation cost of this? And in the same breath you accuse my >> proposal of being "unproven"? Give me a break... >> >> Correct me if I'm wrong but the way I see it is that you want to >> revert the last 2-3 months of my work because you have an investment >> in an old version of the spec. With each day I spend on OCCI costing >> me well over €1,000 excuse me for being pissed about someone with >> such a blatantly obvious conflict attacking my work and refusing to >> provide a coherent argument, particularly with no "camera ready" >> alternative anywhere in sight. >> >> Sent from my iPhone >> >> On 20/10/2009, at 16:51, Gary Mazz <garymazzaferro(a)gmail.com> wrote: >> >>> I've understood Sam's proposal from the beginning. I have had issue >>> with from the beginning. >>> >>> Although I find it very interesting and valuable in terms of >>> economy, I have issue with it as the OCCI's primary interface >>> implementation for a few reasons which have been outlined in several >>> other emails. >>> >>> It appears that Sam has created a new technology, a lower cost RPC >>> mechanism, which is unproven for both small and wide scale >>> deployment. For interoperability, IMO, occi should focus on proven >>> mainstream technologies as the primary interfaces. I am not >>> suggesting, shelving or not supporting Sam's proposal, based on >>> market acceptance, it may prove to be one of many occi interface >>> implementations. >>> >>> As for cost saving in interface technologies, I do not buy into the >>> idea that the occi traffic will be so overwhelming that there is a >>> requirement to maximally optimize http requests and responses. IMO, >>> in comparison to images and consumer data occi traffic will be >>> insignificant. I think we are worrying about spilled milk while the >>> house is burning. >>> >>> There has been some discussion on supporting technologies including >>> OVF. Whether occi supports OVF has not been fully discussed, >>> examined or any consensus reached. I believe adopting technologies >>> like OVF will only lead to mapping issues between occi attributes >>> and the external formats creating a long term management headache. >>> >>> cheers, >>> gary >>> >>> >>> Alexis Richardson wrote: >>>> OK >>>> >>>> Is Sam's statement something that we can achieve consensus around? >>>> >>>> a >>>> >>>> >>>> On Tue, Oct 20, 2009 at 12:47 PM, Sam Johnston <samj(a)samj.net> >>>> wrote: >>>> >>>>> Alexis, >>>>> >>>>> Seems our posts crossed in the mail. I hope the last one clears >>>>> things up >>>>> but the fact that you're using OVF and XML/JSON interchangeably >>>>> suggests >>>>> that you [are possibly one of many who] don't grok the proposal. >>>>> Worse, it >>>>> seems you've got it back to front in thinking of the "core" as >>>>> metadata, >>>>> which is not at all what I had intended. >>>>> >>>>> The focus is on the resources and their various representations. >>>>> The >>>>> metadata (that is, data about data) essentially provides >>>>> whatever is >>>>> necessary to "glue" these resources together. It is basically >>>>> using HTTP as >>>>> the meta-model rather than an envelope format like Atom/SOAP or, >>>>> worse, a >>>>> meta-model that we have to create ourselves from scratch. >>>>> >>>>> So it's more like: >>>>> >>>>> 1) OCCI is compatible with ALL existing formats, eg OVF >>>>> >>>>> 2) Existing formats are used are used for ALL representations >>>>> >>>>> 3) ALL additional metadata should be in the headers >>>>> >>>>> 4) ALL of the core stuff should be in the body (that is, the >>>>> metadata in the >>>>> headers is just there to support the data and wire it up in useful >>>>> ways) >>>>> >>>>> I think the confusion stems from your assuming that there is still >>>>> XML/JSON/Atom/etc. representations. There aren't. HTTP headers >>>>> provide a >>>>> single, performant, interoperable metadata channel that has >>>>> already been >>>>> both standardised and extensively implemented. >>>>> >>>>> If you've followed me this far then you should have realised that >>>>> every HTTP >>>>> user agent (e.g. Perl's LWP, Python's urllib2, C's libcurl, etc.) >>>>> is already >>>>> a basic OCCI client out-of-the-box. The result is that 5-line >>>>> scripts like >>>>> demo.py are functional with no dependence on client libraries >>>>> (that would >>>>> absolutely be necessary if you were to start trying to define your >>>>> own >>>>> formats). >>>>> >>>>> Sam >>>>> >>>>> PS I'm sorry my "bunk" comment came across as referring to you >>>>> personally - >>>>> it was directed at the argument. >>>>> >>>>> On Tue, Oct 20, 2009 at 12:44 PM, Alexis Richardson >>>>> <alexis.richardson(a)gmail.com> wrote: >>>>> >>>>>> 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(a)samj.net> >>>>>> wrote: >>>>>> >>>>>>> On Tue, Oct 20, 2009 at 12:28 PM, Edmonds, AndrewX >>>>>>> <andrewx.edmonds(a)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(a)ogf.org [mailto:occi-wg- >>>>>>>> bounces(a)ogf.org] On >>>>>>>> Behalf >>>>>>>> Of Alexis Richardson >>>>>>>> Sent: 20 October 2009 09:49 >>>>>>>> To: Sam Johnston >>>>>>>> Cc: Tim Bray; occi-wg(a)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(a)samj.net> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Tue, Oct 20, 2009 at 9:55 AM, Alexis Richardson >>>>>>>>> <alexis.richardson(a)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(a)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(a)samj.net> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On Tue, Oct 20, 2009 at 12:57 AM, gary mazzaferro >>>>>>>>>>>> <garymazzaferro(a)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(a)ogf.org >>>>>>>>>>>> http://www.ogf.org/mailman/listinfo/occi-wg >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> occi-wg mailing list >>>>>>>>>>> occi-wg(a)ogf.org >>>>>>>>>>> http://www.ogf.org/mailman/listinfo/occi-wg >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> occi-wg mailing list >>>>>>>> occi-wg(a)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. >>>>>>>> >>>>>>> >>>>> >>>> _______________________________________________ >>>> occi-wg mailing list >>>> occi-wg(a)ogf.org >>>> http://www.ogf.org/mailman/listinfo/occi-wg >>>> >>>> >>> >>

3 3

GridForge down again?
by Sam Johnston 20 Oct '09

20 Oct '09

There's some discussion <http://twitter.com/GeorgeReese/status/5005229849>of the OCCI FeatureMatrix on twitter and it seems GridForge is down again: [Exception in:/common/jsp/menus/top.jsp] Unable to render widget *A SourceForge system error has occurred. An unexpected system error has occurred* If you feel you have received this message in error, please contact the SourceForge administrator and reference this tracking number: exid41B6B5B501246F53D5018763 While it's great to have some external discussion going on this getting is a little embarrassing... at least the Google Code component is up most of the time (if read-only for a few hours here and there - which is still more often than I would like). Sam

3 4

About deleting a resource and what to return
by Tino Vazquez 20 Oct '09

20 Oct '09

Hi all, I have a doubt regarding the spec. In the OpenNebula implementation, whenever a resource is deleted we return a confirmation message with a 200OK status, but I don't think this is completely adecquate. As the spec is not clear in this aspect (or I couldn't figure it out) I would like to ask which would be the best way to proceed. Shall we return nothing but the status, the representation of the deleted object or rather just the ID of the deleted object? What do you think. Cheers, -Tino -- Constantino Vázquez, Grid Technology Engineer/Researcher: http://www.dsa-research.org/tinova DSA Research Group: http://dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org

2 2

GridForge down?
by shlomo.swidler＠gmail.com 19 Oct '09

19 Oct '09

Hi guys, I get this error when I try to access any GridForge page: [Exception in:/common/jsp/menus/top.jsp] Unable to render widget A SourceForge system error has occurred. An unexpected system error has occurred If you feel you have received this message in error, please contact the SourceForge administrator and reference this tracking number: exid41B6B5B5012469CE36A5567D - Shlomo.

2 1

Re: [occi-wg] Fwd: New Version Notification - draft-dusseault-http-patch-15.txt
by Sam Johnston 19 Oct '09

19 Oct '09

[moving this off-list discussion to the list where it belongs] On Sun, Oct 18, 2009 at 12:40 PM, <AC> wrote: As we move closer to practical working set of management actions, it appears > we are moving further away from ReSTful principals. Now, we have 4 > additional actions HEAD, OPTIONS, MOVE, and PATCH over the ReST CRUD. We > haven't even begun to here from user wanting CHECKPOINT, COPY and CLONE (a > live checkpoint copy). All of these verbs are useful and none of them are particularly non-RESTful - in fact they're effectively performance optimisations: - HEAD allows one to retrieve metadata without the entire (possibly large) representation - OPTIONS allows you to "look before you leap" - COPY allows a remote client to request a resource be transferred (short for GET followed by PUT, only allows e.g. EDGE connected iPhones to participate) - MOVE is like COPY, only it's short for GET-PUT-DELETE (again avoiding the need to transfer the whole lot via the client) - PATCH is like PUT, only it doesn't require the entire entity to be transferred (rather just the changes in e.g. diff format) Without these optimised HTTP verbs it would be literally impossible to, for example, migrate a virtual machine from one cloud to another from a client sitting on a "slow" connection like 3G/EDGE/GPRS, or even ADSL. Note also that they have all been standardised at some point by the IETF, either in HTTP itself or WebDAV. Nobody's talking about introducing our own non-standard HTTP verbs for OCCI. Using SSL and other secure protocols, we eliminate any possibility to > leverage existing document cache infrastructures. > No, we eliminate the possibility for *untrusted intermediaries* to cache, which is by design. As OCCI continues to mature towards practical design, many aspects of ReST > seems to be incompatible with real world management applications. Outside > of the resource addressing scheme, which is very similar to SNMP and > CMIP/CMOT in concept, ReST provides very little to guide the direction of > our technical decisions. In fact, the more I think of it, the more it looks > like "snake oil". It appears to have a large following of "devotees", > drinking that koolaid and blindly chant a ReST mantra. The scary part is, > most don't have a clue of impacts or its proper application. > Attacking an API for being RESTful after it's been written (based on a clear consensus to be RESTful no less) is not what I would call "constructive criticism", especially when framed as a religious debate when it's not. There are plenty of forums for such "discussion" but this isn't one of them - we're assessing all the options on technical merit with a view to reaching a rough consensus and producing running code (even if we're not the ones writing it). If you insist on having this discussion then I would suggest focusing on the content rather than the contributors, for example by highlighting specific instances where REST fails to deliver *and* where RPC would have done a better job. Good luck with that. Sam -<AC> > > Sam Johnston wrote: > >> On Fri, Oct 16, 2009 at 7:32 PM, <AC> wrote: >> >> >> And, how does this impact the implementation of ReSTful principals >> as called out in the last draft of the occi specification ? >> >> >> It doesn't. It just provides a shortcut for someone who wants to make a >> minor change (e.g. the number of compute cores) to a large representation >> (e.g. OVF for an entire cluster). >> >> Sam >> >> On Fri, Oct 16, 2009 at 4:09 AM, Sam Johnston <samj(a)samj.net >> <mailto:samj@samj.net>> wrote: >> >> Afternoon all, >> >> The HTTP PATCH verb is interesting in that it allows you to >> update a representation without having to transfer the entire >> thing. It's a space-time tradeoff in that it's a smaller >> transfer but you then have to generate and apply the patch, >> but for large/complex representations and remote (e.g. iPhone) >> users it could provide significant benefit. I wouldn't suggest >> that it be required at this time given lack of implementation >> (e.g. Apache) support but I've added a reference to it to OCCI >> as it will be useful for some applications and I'd rather >> provide the functionality than have people invent it. >> >> It's worth noting that PATCH first made an appearance (along >> with LINK and UNLINK) in the first HTTP RFCs but wasn't >> included in more recent releases due to lack of implementations. >> >> Sam >> >> ---------- Forwarded message ---------- >> From: *Mark Nottingham* <mnot(a)mnot.net <mailto:mnot@mnot.net>> >> Date: Fri, Oct 16, 2009 at 1:48 AM >> Subject: Fwd: New Version Notification - >> draft-dusseault-http-patch-15.txt >> To: HTTP Working Group <ietf-http-wg(a)w3.org >> <mailto:ietf-http-wg@w3.org>> >> >> >> >> >> New version (-15) has been submitted for >> draft-dusseault-http-patch-15.txt. >> >> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-15.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-dusseault-http-patch-15 >> >> IETF Secretariat. >> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> >> _______________________________________________ >> occi-wg mailing list >> occi-wg(a)ogf.org <mailto:occi-wg@ogf.org> >> http://www.ogf.org/mailman/listinfo/occi-wg >> >> >> >> >

3 7

Re: [occi-wg] Modeling proposal for ReST/Cloud based commands.
by Sam Johnston 18 Oct '09

18 Oct '09

Bill, Ironically Adrian wrote this post after being prompted by myself and Andy Edmonds from the OCCI-WG following criticism of exactly this approach. I definitely think links are a great way of satisfying the hypertext constraint (formerly known as HATEOAS) but I'm intrigued by what specific problems he has with this approach - e.g. "what could possibly go wrong"? In many (most?) cases the "actions" are not parametrised in which case the entity-body is empty, but the alternative, doing an empty POST to a parametrised (GET-style) URL, feels [very] wrong. While URLs should be considered opaque, I'm ok with using either semicolons or path segments ('/') to delineate actions: http://example.com/vm01;start but the following "feels funky": http://example.com/disk01;resize=20000 I much prefer: POST http://example.com/disk01;resize size=20000 So what we are currently doing for "actions" is a post/redirect/get pattern<http://en.wikipedia.org/wiki/Post/Redirect/Get>which I feel is quite elegant in that it allows us to handle more challenging realities such as asynchronous responses (e.g. returning HTTP 201 Accepted with a Location: header which can be monitored ala pubsubhubbub or polled). Adrian was talking about servers returning 409 Conflict but I don't have a problem with that either - if so the client knows it can try again later and doing anything else (like saving and replaying the request on the server side) doesn't seem right to me either as it's a form of server-side state. Anyway it's good to see this all starting to coalesce - just need to sort out the nitty gritty details. Sam On Thu, Oct 15, 2009 at 1:43 AM, Bill Burke <bburke(a)redhat.com> wrote: > > Well, the more restful way of doing it would be: > > GET of /objects/robot/3333 returns: > > {"robot" : > {"name" : "Mr. Roboto", > "links" : [ {"rel" : "kill", "href" : "http://.../objects/robot/3333/kill", > "type" : "application/x-form-urlencoded}] > } > } > > So, the idea is you get the representation of the robot, and the links > define what relationships are to the robot. One of the relationships is > "kill". You follow the link by posting to it: > > POST /objects/robot/333/kill > > death=slow > > GET of /objects/robot/333/kill might return: > > "This robot died a slow death" > > The thing is here that the URL patterns are irrelevant, the URLs are > opaque, you navigate to them by linking. > > > Adrian Cole wrote: > >> sorry.. the rendering is bad in firefox. >> >> Here's the matrix example: >> >> POST http://localhost:8080/objects/robot/action/kill;death=slow HTTP/1.1 >> >> Here's the entity example (objects renamed from a real cloud api): >> >> POST http://localhost:8080/objects/robot/action HTTP/1.1 >> Content-Length: 25 >> >> {"kill":{"death":"slow"}} >> >> >> This is probably more high-level, but if it is rest to address resources >> as /path/to and operate them with POST, DELETE, etc, it may come naturally >> for some who are FSMs to offer state transition commands. In this case, >> simple command patterns come in handy and are currently in use in compute >> clouds, for example. >> >> I hope this background helps. If the topic doesn't fit the list, let me >> know. >> Cheers, >> -Adrian >> >> >> On Wed, Oct 14, 2009 at 2:55 PM, Bill Burke <bburke(a)redhat.com <mailto: >> bburke(a)redhat.com>> wrote: >> >> >> REST is not an RPC model...Or maybe I'm misinterpreting you. Also, >> the code examples in your blog are cut off. >> >> >> Adrian Cole wrote: >> >> Hi, all. >> >> I'd like your opinion on modeling ReST commands on the server >> side. I've placed a suggestion for thought on my blog [1]. >> Please let me know what you think. The basic idea is to prefer >> not using entities on commands as it makes retry logic easier. >> In such case, we can use Matrix Params instead. >> >> Cheers. >> -Adrian >> founder jclouds >> >> [1] >> >> http://anyweight.blogspot.com/2009/10/rest-be-nice-no-entities-please.html >> >> >> http://www.reddit.com/r/programming/comments/9u2ic/rest_be_nice_no_entities… >> http://digg.com/programming/ReST_be_nice_no_entities_please >> >> >> -- Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> >> >> > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com >

3 5

Fwd: [rest-discuss] hateoas - draft #1
by Sam Johnston 16 Oct '09

16 Oct '09

This thread on rest-discuss<http://tech.groups.yahoo.com/group/rest-discuss/>discusses the relationship between a *resource* and its *representations*. It's a core REST tenet and it's important that it's well understood: Modeled resources e.g. people, bank accounts, computers, etc. (generally) can't be transferred over HTTP. As such we rely on "representations" which convey information describing the resource - for a person it might be a photo, XML descriptor, rendering of a drivers license or other ID, fingerprints, DNA sequence, etc. - none of these are the actual person but they all describe some characteristic(s) of them. Updating the person's name by posting a representation of their drivers license should result in updates to the person's passport and XML descriptor. In relation to OCCI it may be possible to create a VM by PUTting an OVF file and it may also be possible to GET representations in other formats - e.g. Xen, Hyper-V, VMware. Just because you can render a representation doesn't guarantee that you can read it however so updates using an unsupported format should trigger a 415 Unsupported Media Type error. Sam ---------- Forwarded message ---------- From: Sam Johnston <samj(a)samj.net> Date: Fri, Oct 16, 2009 at 1:34 PM Subject: Re: [rest-discuss] hateoas - draft #1 To: Mike Kelly <mike(a)mykanjo.co.uk> Cc: Jan Algermissen <algermissen1971(a)mac.com>, Will Hartung < willh(a)mirthcorp.com>, "rest-discuss(a)yahoogroups.com List" < rest-discuss(a)yahoogroups.com> On Fri, Oct 16, 2009 at 1:05 PM, Mike Kelly <mike(a)mykanjo.co.uk> wrote: > > >> PUT /resource.xml > >> > >> what does that mean for > >> > >> /resource.json > >> /resource.atom > >> > >> .. How would intermediaries know that the state of the json and atom > >> resources (that are really just representations of the same > >> resource) have also changed? > > > > Well, if you PUT some XML to a resource and it response with 2xx then > > there will not be any json or atom anymore because you told the server > > to explicitly replace whatever state the resource has with the XML. > > I believe this to be a fundamental misinterpretation of what it means to > PUT a representation. The significance of the request is to update the > *resource* state by transfering an XML representation - this should not > cause other the other representations to cease to exist. That doesn't > make sense to me if they are simply representations of the resource that > has been updated - regardless of which specific representation caused > the update. > Exactly. As another example, if an OCCI <http://www.occi-wg.org/>implementation supports multiple formats for virtual machines (say, OVF, Xen and Hyper-V) then PUTting (or PATCHing<http://tools.ietf.org/html/draft-dusseault-http-patch>) any one of these formats will update the *resource* and with it all of its representations. If the support is export-only (that is, it is able to render the resource to it but not parse and update the resource from it) then such requests should be rejected with e.g. 415 Unsupported Media Type. Sam

1 0