- occi-wg - lists.ogf.org

help needed & this weeks OCCI concall
by Thijs Metsch 06 Oct '09

06 Oct '09

Hi, There will not be any draft build today since there are no changes made to the repository. Please people have a look at the issue list at code.google.com/p/occi and help fix some. On this weeks concall we will discuss the OGF27 agenda and schedule. During this call we also need to figure out when we will submit the draft to the OGF editor pipeline. Presumable this will be next week on Wednesday. All the best, -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

4 5

Fwd: [wg-all] New documents in public comment
by Thijs Metsch 05 Oct '09

05 Oct '09

And one of the 3 documents is ours :-) Cheers, -Thijs Begin forwarded message: > From: Greg Newby <newby(a)arsc.edu> > Date: October 5, 2009 6:51:25 PM GMT+02:00 > To: All OGF <wg-all(a)ogf.org> > Subject: [wg-all] New documents in public comment > > To all OGF group members and affiliates: > > Three new documents are available for public comment, and there is > still time to comment on two previously available. > > All documents in public comment may be reached at this Web address: > http://www.ogf.org/gf/docs/?public_comment > > * Open Cloud Computing Interface - Use cases and requirements for a > Cloud API. T. Metsch, via OCCI-WG. > > * WS-Agreement Specification Version 1.0 Experience Document. > D. Battre, P. Wieder, W. Ziegler, via GRAAP-WG > > * WS-DAI and WS-DAIR Implementations - Experimental Document. > S. Lynden, M. Antonioletti, M. Jackson, S. Ahn, via DAIS-WG > > These have just a few days left: > > * INFOD 1.0 Implementation--Experience Report. R. Fehling, S. Fisher, > D. Gawlick, R. Gunasekaran, M. Shankar, A. Yalamanchi, via INFOD-WG. > > * Multi-Server Based Namespace Data Management of Resource Namespace > Service. L. Guo, X. Wang, M. Xu, W. Zhou, via GFS-WG > > > Please consider reading documents in public comment, and providing > your comments to the document authors via the link provided for each > document. Brief comments are welcome, not only detailed analysis. > Public comments are an excellent indication of community interest and > support for a document. > > > -- Greg Newby, OGF Editor > > Dr. Gregory Newby, Chief Scientist of the Arctic Region > Supercomputing Center > Univ of Alaska Fairbanks-909 Koyukuk Dr-PO Box 756020-Fairbanks-AK > 99775-6020 > e: newby AT arsc.edu v: 907-450-8663 f: 907-450-8603 w: www.arsc.edu/~newby > -- > The wg-all mailing list is an umbrella list for all > OGF mailing lists. If you are subscribed to any OGF > mailing list, you will receive mails to wg-all. > > You can unsubscribe from this list on > > http://www.ogf.org/cgi-bin/perl/unsubscribe-wg-all.pl > > wg-all mailing list > wg-all(a)ogf.org > http://www.ogf.org/mailman/listinfo/wg-all

1 0

Fwd: Support Documentation for Today's Meeting
by Tino Vazquez 05 Oct '09

05 Oct '09

Hi Richard, comments interspersed, On Thu, Oct 1, 2009 at 10:40 PM, Richard Davies <richard.davies(a)elastichosts.com> wrote: > First of all, congratulations to Ignacio, Tino and the UCM team on producing > the first implementation of an OCCI draft - real progress and good work! > I wasn't on the call, but have had a quick look through the links which > Ignacio sent. Thanks a lot. *blush* > > > One thing which this brings home to me is that there is still significant > work to tie down unresolved areas the OCCI draft so that implementations > will actually be interoperable. > > This isn't to criticize the UCM team at all - they have done a good job > working from a draft specification and invented plausible mechanisms to fill > gaps where they have found them. > > Nevertheless, I can see quite a few areas in the their draft specs which > clearly (& necessarily) go beyond what the Sep 21 specification draft (the > last which I read) had actually defined. Indeed, we took the liberty of implementing things that weren't present in the OCCI specification in order to dynamize the discussions. In any case, we don't regard our implementation as final (not even close) and we are open to make the neccessary changes to comply as much as possible with the specification (always taking our possibilities into account). > > > Taking one example from their site: > > <COMPUTE> > <NAME>MyCompute</NAME> > <STORAGE> > <SWAP size="1024" dev="sda2"/> > <DISK image="ab5c9770-7ade-012c-f1d5-00254bd6f386" dev="sda1"/> > <FS size="512" format="ext3" dev="sda3"/> > </STORAGE> > <NETWORK> > <NIC network="23" ip="192.168.0.9"/> > </NETWORK> > </COMPUTE> > > This uses XML nesting to specify when storage and network resources and > linked into a compute resource, and has solved several issues such as the > local devices to be used for the storage resources and naming of interfaces. > > By contrast, the Sep 21 specification suggests having separate entries for > each resource, and linking them together using mechanisms similar to the > HTTP Link header (with no example given). The spec doesn't yet say anything > about how local devices should be specified. I agree that the specification should indicate how to link storage and network to virtual machines more clearly. Not sure what you mean by local devices, could you please elaborate more on this? > > > Another example: UCM do not use any extra management verbs. > http://www.ogf.org/pipermail/occi-wg/2009-September/001235.html > By contrast the Sep 21 spec hints that some will exist, but does not define > any of them. You are rigth, the verbs should be specified. We chose another mechanism using updates through PUT to achieve the same thing (more RESTful in my opinion, but also suffering from it, as changing a state is not always guaranteed) > > > My feeling is that the main areas where the UCM team have had to innovate > their own solutions are very similar to the list of areas which I had > previously highlighted as needing resolution in my mail: > http://www.ogf.org/pipermail/occi-wg/2009-September/001215.html > > However, I'd also be keen for the UCM team themselves to write down a list > of the areas where they believe that they had to go beyond the actual > written OCCI drafts to produce something workable. >From our experience, the spec needs to define clearly the states that a COMPUTE resource can be in. From the last conf call the general feeling was that it would be very difficult to agree on one state machine diagram. I vouche for trying to agree on a minimal one, or at least, as Sam suggested, have a registry were the states are well defined. We will be then be happy to implement the mangement verbs instead of relying in the PUT method we currently use. Other issue is aligned with something you point out in your mail, that is, the attributes of the resources. We completely agree with the idea of adding units (as OVF does), although I don't know which will be the best to do so (a string separated by a space with "numbers units", or an extra attribute for each attribute that needs units to be defined?). This will make the spec more flexible. Also, the state should be part of the COMPUTE attributes (in fact, we added it in our implementation because we needed it to update the COMPUTE state). About the decission of theformat of the representations I think it will be shooting our own foot to ask implementators to support each three formats, even if we do so for interoperabilities sake. We need to chose between one or take into consideration Sam's proposal of using HTTP headers for the metadata. > > And I'd be equally keen for Sam to take a careful look through the UCM links > below, identify every place that the UCM implementation doesn't look like > what he had expected and tighten the draft in these areas to either the UCM > solution or whatever he had intended to write but not yet written. > > Cheers, > > Richard. Regards, -Tino > > > Ignacio Martin Llorente wrote: >> Hi, >> >> Because we are now (at 16:00 CEST) discussing the OpenNebula OCCI >> implementation, I am sending some links with relevant info: >> >> - OpenNebula OCCI API Specification: http://www.opennebula.org/doku.php?id=documentation:rel1.4:occidd >> - Usage Guide: http://www.opennebula.org/doku.php?id=documentation:rel1.4:occiug >> >> Cheers, >> >> -- >> 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 > -- 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

3 3

Great developer-focused use cases for Infrastructure APIs
by shlomo.swidler＠gmail.com 02 Oct '09

02 Oct '09

Just a quick note to call to everyone's attention this great article presenting developer-centric requirements for a cloud API. http://www.1060.org/blogxter/entry?publicid=12CE2B62F71239349F3E9903EAE9D1F0 .. Shlomo

2 1

Support Documentation for Today's Meeting
by Ignacio Martin Llorente 01 Oct '09

01 Oct '09

Hi, Because we are now (at 16:00 CEST) discussing the OpenNebula OCCI implementation, I am sending some links with relevant info: - OpenNebula OCCI API Specification: http://www.opennebula.org/doku.php?id=documentation:rel1.4:occidd - Usage Guide: http://www.opennebula.org/doku.php?id=documentation:rel1.4:occiug Cheers, -- 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

2 1

Reminder: IGT on going work groups meetings and events
by IGT 30 Sep '09

30 Sep '09

<http://www.grid.org.il/_pics/NewsLetterHeader.jpg> IGT on going work groups meetings and events http://www.grid.org.il/?CategoryID=384 <http://www.grid.org.il/?CategoryID=384> And.. Please do not forget our annual event on Dec 2-3: IGT2009 – The World Summit of Cloud Computing http://events.myreg.co.il/IGT2009/ <http://events.myreg.co.il/IGT2009/> מחק אותי מתפוצת אימייל זה <http://www.grid.org.il/?pg=subscr_un> | כניסה לאתר <http://www.grid.org.il>

1 0

Comments, Suggested Changes for Walkthrough
by Edmonds, AndrewX 30 Sep '09

30 Sep '09

Hi all, I've gone through the walk through and have a list of comments and suggested changes. I will be continuing on through the spec with a similar intention of contributing comments and suggested changes. Thijs, if you like I can add these to the tracker unless you want to pre-process them? I do not suggest discussing any of these via the mailing list. That discussion can happen via the issue tracker. Andy * General * Would be useful to introduce the notion of OCCI extensions in the walk through * A page break should be inserted to separate the walkthrough and "OCCI Core Specification" * Revise usage of brackets * Paragraph 4 "resource or type of resource" * what's the difference here? * Paragraph 4 "and search" * note that this is an extension and may not be supported in all implementations * Paragraph 5 Bracket usage in the sentence "Certain types of accesses..." * would read better as: Certain types of accesses, such as a compute resource querying OCCI for introspection and configuration, may be possible anonymously in the case where the query has already been authenticated by interface and/or IP address. * Paragraph 6 "Should you be redirected by the API to a node, storage device, etc. (for example, to retrieve a large binary representation) then you should either be able to transparently authenticate or a signed URL should be provided." * If the basic authentication is not cached then this transparent authentication will not happen. Is what I say a correct statement? * Paragraph 6 "(at least not yet!)" * Remove this, not necessary. * Paragraph 6 "and while OCCI standardises a number of them for interoperability" * We can only recommend other standards for use in OCCI not standardise them - that's the responsibility of the relevant standards body * Paragraph 6 List of representations * I do not agree that a screenshot or access to console is an appropriate general entity representation like what OVF/OVA are. These items are more suitable as attributes in an entity representation (OVF/OVA/OCCI). Suggest removing or noting that they are lesser forms. * Paragraph 7 "The client indicates which representation(s) it desires by way of the URL" * An example illustrating this might be useful e.g. * To request a HTML rendering, if supported, of a compute node issue http://example.com/path/to/compute/resource/123-123-123.html * The same might be for the content negotiation. * Paragraph 8 "In addition to the protocol itself," * Remove the protocol includes interaction semantics, syntax and data schemas. * Paragraph 8 "In addition to the protocol itself, OCCI defines a simple key/value based descriptor format for cloud infrastructure resources:". * Reword to: "OCCI defines a simple key/value based descriptor format for cloud infrastructure resources. These infrastructure resources as defined by OCCI are:". * Paragraph 8 Formatting * Embolden compute storage and network - these are core concepts to OCCI. * Paragraph 9 Comment * If we say that it is trivial to translate and present an example that example should show the trivial translation. In this case we should add the XML and JSON examples. * Paragraph 10 Starting "The primary drawback is that" ending "or HTTP 410 Gone otherwise)." * Is this necessary here - might be better moved out of the walkthrough to elsewhere or just removed. * Paragraph 10 Comment * Bracket usage should be reviewed. * Paragraph 12 "UUIDs anyway" * Remove "anyway". * Paragraph 12 "used instead (e.g. http://amazon.com/compute/ami-ef48af86)" * Any significance using this URL - better we use something fictional * Paragraph 12 "can be safely allocated by any node" * What's a "node"? A resource? A resource manager? * Section 2.3 Comment * A brief introduction should be inserted here. * Paragraph 13 "POST it to" * What is "it"? Explicate. * Paragraph 13 "as an HTML form" * More correct to say "POST the attributes and values using the application/x-www-form-urlencoded format" * Paragraph 15 "to GET a template" * New concept introduced with no explanation. Explain briefly (footnote?) or drop and move discussion elsewhere in doc. * Paragraph 15 "POST or PUT it back" * There are semantic differences here that should be noted to the reader. * Paragraph 17 P18 Comment * It would make more sense to inform the user how to get a list of supported renders per provider first and then tell how to request it. As it initially reads it appears that 2 calls are needed. * Paragraph 19 "There are two options:" * Better phrased as "There are two concepts that are supported" * Paragraph 19 "such as searches" * Change to "such as the collections returned from the search extension" * Paragraph 19 Pass-by-ref, pass-by-value * This is more a metaphor - might be worth explaining what is meant by these explicitly, otherwise the reader is left to interpret. * Paragraph 20 "Update" * It says to PUT but I can also update via POST and be naughty. * Paragraph 22 Comment * What about "Resource Child Collections". * Paragraph 22 Comment * These are in effect extensions to the core and so should be noted as such. * Paragraph 24 "Requests" * Just a comment - isn't this very RPC-like something that REST aims to avoid? * Paragraph 24 "Requests" * A number of request types are mentioned but nowhere in the spec are they detailed. Andy Edmonds skype: andy.edmonds tweets: @dizz ------------------------------------------------------------- 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 9

Proposal for conference call to discuss OCCI attributes in HTTP headers
by Gary Mazz 30 Sep '09

30 Sep '09

I' like to schedule a meeting to discuss Sam Johnston's proposal to move OCCI attributes elusively to HTTP headers. I'd like to schedule this conference on friday Sept 25, 2009, the as time as the weekly call. We need to fully understand the mapping of the attributes to the http protocol structures and the impacts to the specification. cheers, gary mazz

3 8

OCCI Specification draft
by Thijs Metsch 29 Sep '09

29 Sep '09

Hi @all, This is the first (almost final :-)) draft of the OCCI Specification. It reflects the changeset #47 in the source code repository (Date Sep. 21 2009). This release has been tagged. For easier discussion on the concall on Wednesday all the paragraphs have been numbered. The document can be downloaded here: http://forge.ogf.org/sf/docman/do/downloadDocument/projects.occi-wg/docman.… our http://www.occi-wg.org website also links there. We'll do a walkthrough of the complete specification on our concall on Wednesday so please review the document and join the call. All the best, -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

5 7

New specification document draft
by Thijs Metsch 29 Sep '09

29 Sep '09

Hi, I uploaded a new draft of the spec. Not much changed so please help filling in the holes: http://code.google.com/p/occi/issues/list Have a look here: http://forge.ogf.org/sf/go/doc15731?nav=1 I will work on the issues: 2, 14, 18 I also updated the issue tracker templates. So when creating a new comment use the document_comment template. It tells you what information is need to comment :-) Is also include the changeset #49 and date 29.09.2009... All the best, -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