- occi-wg - lists.ogf.org

OCCI-wg concall - Wednesday June 10, 2009 @ 5pm CET
by Thijs Metsch 08 Jun '09

08 Jun '09

Hi guys, It is again time for our weekly concall. This time I think their is a lot to discuss. First of all OGF26 is over and after some weeks of discussions with several people I think it is necessary to get back on track, and get some lively discussions back :-) Therefore the current agenda looks like: 1. Short announcement from the chairs 2. Update on the progress of the last weeks 2. Requirements and Use cases 3. API discussion If you want more topics and discussions please add your topics: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Concall20090… So please take some time and join the discussion. The concall data is located here: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… The concall starts at at 5pm CET, 08am PDT, 11am EDT, 4pm BST. For your timezone information - have a look at the wiki :-) All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

Fwd: HTTP is Dead, Long Live The Realtime Cloud
by Sam Johnston 03 Jun '09

03 Jun '09

FYI, some pertinent discussion about HTTP from another list. ---------- Forwarded message ---------- From: Sam Johnston <samj(a)samj.net> Date: Wed, Jun 3, 2009 at 3:38 PM Subject: Re: HTTP is Dead, Long Live The Realtime Cloud To: cloudforum(a)googlegroups.com On Wed, Jun 3, 2009 at 3:04 PM, Gregg Wonderly <greggwon(a)gmail.com> wrote: > HTTP is not really the power point of web delivery. AJAX, HTML, CSS, DHTML > etc standards are what make it powerful. REST is a useful architectural > model, and application protocols on top of HTTP can still extend the model > to provide more powerful application APIs that will simplify development of > advanced web delivered applications. Pretty much everything (useful) is built on top of HTTP and if anything the lesson we should learn from previous attempts to deviate from it (SOAP, XML-RPC and WS-*) is that we should in fact be embracing it and getting as close to it as possible. Earlier (in the context of OCCI development) I asked Is AtomPub already the HTTP of cloud computing?<http://samj.net/2009/05/is-atompub-already-http-of-cloud.html>, figuring that it delivered the out-of-band "Web Linking" that HTTP couldn't (traditional web linking is in-band, through use of HTML's "A" and "LINK" elements, but that doesn't work for non-HTML payloads like OVF, ODF, etc.). There was (unfortunately) huge backlash from the XML-xenophobes (I say unfortunately because the RealCloud™ players, most notably Google and Microsoft, have adopted it strategically for pretty much everything they're doing in the space) so it has been dropped at least for the time being from individual resources (even if it remains for collections, ironically increasing complexity by requiring two different approaches depending on cardinality). Anyway if you ignore the problem of collections (which can be passed either by reference as a plain text list of links, or by value with a meta-model like Atom - with O(n+1) and O(1) performance respectively) then it turns out HTTP actually provides for web linking in the earlier drafts, by way of the Link: HTTP header and the LINK and UNLINK HTTP verbs. Obviously the guys responsible for writing this stuff could see further into the future than the guys implementing it! The point is that using native HTTP it is possible to create an extremely RESTful, scalable and trivial to use "Resource Oriented Architecture (ROA)" that "just makes sense" - every resource has a URL and can be retrieved in various representations (e.g. a DOC could also be retrieved as PDF, a song as MP3 or AAC and a virtual machine as OVF or a PNG screenshot), operations can be repeated without fear of repurcussions, everything can be cached, associations can be created between resources (e.g. a compute resource having a link to storage and network resources), etc. This is far easier to understand and write to than an RPC-based approach often associated with SOA. As for Wave, there's even a "HTTP PATCH" method currently being reincarnated<http://tools.ietf.org/html/draft-dusseault-http-patch-14>that allows you to make specific changes to a document rather than replacing it altogether with a PUT. In summary, HTTP is far more powerful than you might think and given the enormous amount of infrastructure and optimisation built around it you would want to have one hell of a good reason to deviate from it. For Google having an existing XMPP infrastructure (Google Talk) is strong incentive, but that doesn't make it the best approach for the rest of us - work being done around browsers becoming servers is also potentially applicable. Sam

2 1

concall today?
by Thijs Metsch 03 Jun '09

03 Jun '09

Hi guys, In 1h and 10 minutes it is time for our weekly concall. My apologies for the late invitation. I do not have and topics for the agenda. If you have some please add the to our wiki page: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Concall20090… Either way I will open the line and see who joins. Please find the dialin details as usual at: http://forge.ogf.org/sf/go/wiki2128 All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

1 0

moving forward
by Alexis Richardson 01 Jun '09

01 Jun '09

Hi all, I spoke with Thijs today who has been representing OCCI at the current OGF meeting. The feedback from OGF leadership is that they are pleased with our progress and the level of participation. But they would also like us to move on from the deep discussions about formats, a view with which I think *everyone* on the list agrees. A lot has been said about different approaches and we now risk repetition, deviation and hesitation; which I for one do not want to see persist. Now is the time to stake out areas where consensus exists - to try to seek rallying points. Where are those to be found? I met with Sam, Roger from Fujitsu, and Chris and Richard from EH last week and had a set of very interesting conversations. I was left with the feeling that the first task is to identify areas where there is agreement, and from there establish consensus, from which basis a course of action can be proposed. I'd also like to thank Sam for his thoughtful emails on HTTP from his own work after last week's meetings. These give me cause to believe we all want to converge. On the other hand, and negatively, I feel that the level of participation while high has devolved into a few people talking. No matter what the quality of any individual's input, this is NOT the activity the chairs want to see. We want input from others. And we want to hear more from at least two kinds of people: * People with cloud implementation experience who want to implement OCCI. We need more than one prototype implementation for this process to be useful. It will NOT help us to create an OCCI that nobody wants to implement. Let's bring the implementers into the fold more, both open source software people and service providers. * End users who represent real world cases especially from, e.g. enterprises. We don't want to build a castle in the sky and we must look to our requirements to bring us down to earth. Requirements are necessary to move us forward from prior art to the standard. Let's bring more real world requirements to OCCI and make this thing really concrete. So: We all need to reach out to people that we know who can join the conversation. If we have enough of them, we can get enough meaningful participation from implementers and requirements advocates, to hammer out something really plausible. PLEASE can everyone do that - reach out to people. I personally think we have something to show people: we have done good work on the state model, as a group, and Andy et al., have worked on formalising and tidying it up. This is great - but not enough to achieve consensus on the next steps. So, what have we not done yet? We have not focussed on the semantics of RESTful interactions with the cloud - the actual API and interop definitions. I have not seen clear statement of requirements here, rather I fear we have let ourselves get sidetracked by too much talk about HOW the OCCI operations might be expressed, which may impact integration, and not enough about WHAT they do (which is critical for defining behavioural semantics). By the same token (no pun intended), by concerning ourselves with one metamodel style over another, we risk coming to the actual interoperable behavioural protocol as an afterthought. Let's not do that. Because we want to make use of prior art, at this point I am going to quote Andy's email from earlier today: "If we want to take the middle ground yet not sit on the fence it would be a useful exercise to see what [ GoGrid ] and [ Sun ] offer and do not offer? See where our efforts here could improve these published APIs and models?" I think this is so eminently sensible that I am going to PROPOSE A COURSE OF ACTION. Please - everyone - this is my view as one of the three chairs, but I want to appeal to you - is this a plan around which we can proceed - is there consensus here? A) Take the Sun and GoGrid models (and use cases) and see what they offer. These meet the criteria of being open and based on reality. Recall the comparison matrix here: http://spreadsheets.google.com/ccc?key=pGccO5mv6yH8Y4wV1ZAJrbQ B) Because the Sun API provides a RESTful picture of a data center, I suggest we first ask: how can the GoGrid model improve it? At the same time ask: how can the OCCI state model improve it? I'd love to see Andy help us shape this discussion and bring some of the OGF community to bear on the problem - especially the *formal* end of making a clear spec that can facilitate interop. C) With these basics done, let's build from the base we will have created. What requirements do Sun/GoGrid/OCCI not meet? What changes or extensions are needed? This is where I think we really want to hear from people like Sam (eg atom/links/documents/collections/caching) and from cloud providers eg Richard and Chris from EH, and from the enterprise BigCo people. D) Show this work to the people on the list and people watching the conversation. Is this implementable - and are enough people willing to have a crack at implementing a prototype or several prototypes? If so then I would suggest that - at that time - we had reached an OCCI 0.9 draft. Here, Thijs is (a) acting as a liaison point with the other standards bodies like DMTF, and (b) looking at Extension points and alternative renderings. What do people think? Speak out here. Invite people to the list to join this process and they can speak out. Tell people - will this process work? alexis

12 32

Fwd: Versioning?
by Sam Johnston 31 May '09

31 May '09

Oops... including list. ---------- Forwarded message ---------- From: Sam Johnston <samj(a)samj.net> Date: Sun, 31 May 2009 19:20:50 +0100 Subject: Re: [occi-wg] Versioning? To: Mark Masterson <mmasterson(a)csc.com> Mark, Are you implying we might not get it right the first time? ;) I thought I'd mentioned this point before but apparently not... I too had read those references and thus far was planning to leave version cruft out of the purl.org URLs, content types, etc. knowing that it can be easily added later should there be revisions. That said our extension mechanisms should cater for most change (eg new verbs, attributes and perhaps even nouns) without having to break existing systems. Also refer to my earlier rants about the core protocol providing only extensibility. HTTP will likely always be 1.1 but that's not to say the spec is immutable - just look at the Link: headers which will allow us to avoid Atom for individual resources. Sam on iPhone On 5/31/09, Mark Masterson <mmasterson(a)csc.com> wrote: > What about versioning the API? This is surprisingly hard to get right, but > (for many, just as surprisingly) awfully important -- I have seen numerous > enterprisey distributed system efforts fail for just (and entirely) this > reason. There is no mention in any of the three APIs being talked about > here (GoGrid, EH, or Sun) of versioning that I can find? Nor do I recal it > being discussed as a first class design goal on this list yet? On the wiki > there is no mention of it in the API Design section. > > Although I confess that I have never used it in anger, there is a > fascinating proposal for attacking versioning in a RESTful way here: > http://barelyenough.org/blog/2008/05/versioning-rest-web-services/ (with > some caveats here: > http://barelyenough.org/blog/2008/05/versioning-rest-web-services-tricks-an… > ). The REST gurus in this group may well know an even better way to solve > the problem. > > I'd be interested in hearing others' views on this. > > > Mark Masterson > Enterprise architect, troublemaker > CSC > > Financial Services EMEA | m: +49.172.6163412 | Internal blog: Schloss > Masterson | Public blog: Process Perfection > (http://jroller.com/MasterMark/) | mmasterson(a)csc.com | www.csc.com. > > > CSC • This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the mistake > in delivery. NOTE: Regardless of content, this e-mail shall not operate to > bind CSC to any order or other contract unless pursuant to explicit written > agreement or government initiative expressly permitting the use of e-mail > for such purpose ï CSC Computer Sciences Limited • Registered Office: Royal > Pavilion, Wellesley Road, Aldershot, Hampshire, GU11 1PZ, UK • Registered > in England No: 0963578 > _______________________________________________ > occi-wg mailing list > occi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg >

1 0

Fwd: Structured data over TCP?
by Sam Johnston 30 May '09

30 May '09

Tim's presentation is insightful. Highlights (actually it's all good so this is most of the presentation): - Use plain text if... you possibly can. - JSON issues: Watch out for extensibility. - Use JSON if... The expected lifetime of the data is short. - Use XML if... your data is document flavoured or you're worried about i18n, extensibility or reusability. - Inventing New XML Languages: - Time-consuming. - Bureaucratic. - Difficult. - Unpleasant. - Includes complex software development as a sub-task. - Usually fails. - ... so try not to! - Some Good XML Languages - XHTML - DocBook - ODF - Atom - XMPP - UBL - RDF - Design Issue: Model vs. Syntax - “What matters is getting the data model right. The syntax is ephemeral.” vs - “The bits on the wire are the only reality.” - Design Issue: Minimalism vs. Completeness - “Let’s solve the whole problem.” - “Minimum progress required to declare victory.” - XML Schema Definitions (XSD): - Hard to understand, hard to implement, hard to interoperate. - One of the reasons why the SOA/WS-* project is sinking. - XML Extensibility: Three Options - No changes. - Must-Understand policy (e.g. as in SOAP). - Must-Ignore policy (e.g. as in Atom). Morals of the story (IMO): - Bend over backwards to use plain text (if we can) - JSON is more interesting for RPC than ROA (Resource Oriented Architecture) - Avoid inventing new [XML] languages at all costs - 6 of the 7 "good" XML languages have already come up in the context of OCCI (NFI what UBL is) - Model and bits-on-the-wire are both important to us - RELAX NG and XPath is a GoodThing™ - For XML extensibility ignore that which you don't understand (ala Atom) - Solve as much of the problem as we need to now but provide for extensibility later Sam ---------- Forwarded message ---------- From: Tim Bray <tbray(a)textuality.com> Date: 2009/5/27 Subject: Re: Structured data over TCP? To: Patrik Fältström <patrik(a)frobbit.se> Cc: apps-discuss(a)ietf.org 2009/5/26 Patrik Fältström <patrik(a)frobbit.se>: > Do Apps Area have any general feeling about this? I was going to start typing in a lengthy answer but then I remembered I gave a tutorial at IETF70 on the choice of data formats for use in Internet Protocols. It's centered around XML but I think covers many of the other issues that have come up in this. Available for your reading pleasure at http://www.tbray.org/tmp/IETF70.pdf -Tim _______________________________________________ Apps-Discuss mailing list Apps-Discuss(a)ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss

2 2

(no subject)
by Andre Merzky 30 May '09

30 May '09

Could Amazon indeed open it's AWS APIs? Just rumours at the moment though... http://ostatic.com/blog/is-amazon-going-to-open-source-its-web-services-and… -- Nothing is ever easy.

2 1

OCCI in the Economist?
by Alexis Richardson 29 May '09

29 May '09

An oblique reference at the end? http://www.economist.com/opinion/displayStory.cfm?story_id=13740181&source=…

1 0

Revised the Sun API lightly
by Tim Bray 28 May '09

28 May '09

Not in a deep way; in response to people worried about administrative control policies. Here's how it works now: A Virtual Data Center contains a collection of VM templates, a collection of available public IP addresses, and a single Cluster resource. A Cluster resource contains, along with some actuator URIs, a collection of private networks, a collection of virtual machines, and zero or more child clusters. The idea is that the general-purpose Cluster grouping resource now acts just like a nested filesystem. Private networks belong to clusters, but only for administrative purposes; they can be attached to any VM in any cluster. (What's changed? Previously, clusters didn't nest and private- networks were allocated at the VDC level). The motivation is, we hear from people, especially private-cloud people, that they want to hand out authorization rights to control particular sets of VMs and private-networks, but not others. It wasn't obvious how you'd go about doing this. So now everything that you might reasonably want to control/administer has a primary association to a Cluster object, making that the obvious hook to attach administrative-rights policies. (If people don't want these FYI posts about parallel work in another API-building effort, say so and I'll shut up). -Tim

2 1

Agenda for tomorrows meeting @OGF (1:30pm EDT)
by Thijs Metsch 28 May '09

28 May '09

Hi guys, This is the current agenda for tomorrows meeting. There will be 5 presentations: 0. Introduction to OCCI - Thijs Metsch 1. Alexander Papaspyrou 2. Tino Vazquez (via skype) 3. Augusto Ciuffoletti (via skype) 4. Richard Davies (via skype) The first session takes place from 1:30pm till 3pm. The second session will be from 3:30pm till 5pm. The second session is for an open group discussion. All times are given for the EDT timezone. To match it up with your timezone visit: http://www.timeanddate.com/worldclock/meeting.html We'll use the same teleconference bridge as usual. Please see: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… To all presenters: if you haven't done already can you send me the slides? Or at least the conrete titles So I can update the ogf pages accordingly? That would be great! Thanks in advance! All the best, -Thijs -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com

4 9