- occi-wg - lists.ogf.org

RESERVOIR VMI whitepaper available
by Lars Larsson 13 May '09

13 May '09

Fellow OCCI:ers, on behalf of the RESERVOIR project, a whitepaper on the VMI (the interface most closely resembling the OCCI) has been created and uploaded to the OCCI Wiki. You may find it via the Resources page, or using this direct link: http://forge.ogf.org/sf/sfmain/do/downloadAttachment/projects.occi-wg/wiki/… Best regards, -- Lars

1 0

About the wiki
by Tino Vazquez 12 May '09

12 May '09

Hi everyone, I think we should better define the semantics of the concepts presented in [1]. It is my believe that this is way more important than the Wire Protocol choice. I would like to start by a detail definition of the states of the State Model [2]. Even slightly modifications I believe are needed (the "pending" state). But even more importantly we should define what each state "means". That would allow us to tell the difference between "Suspended" and "Stopped". The "Some explanational notes" list is an start, but it needs further refinement. The question is: how do we go about this? Am I welcome to modify the Wiki page? Or shall I start making the suggestion in the list to get consensus? Best regards, - Tino [1] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/NounsV… [2] http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/StateM… -- 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

Use Cases and Requirements
by Ignacio Martin Llorente 11 May '09

11 May '09

Dear OCCI list members, In some of the discussions about implementation, I see that several people stated their interest in contributing use cases and requirements. Please do not forget that you are invited to do so by including new use cases (the use case could be a simple one-line description) at http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/UseCases or even new requirement sources at http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Requirements We are also in the process of extracting the requirements for the use case descriptions: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Requirements… Cheers, Ignacio -- Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org Globus GridWay Metascheduler: http://www.GridWay.org OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org

3 2

Re: [occi-wg] Is OCCI the HTTP of Cloud Computing?
by Cloud Central - Kristoffer Sheather 09 May '09

09 May '09

Hi Randy, Many verbs can be interpreted in different ways, as long as there is an agreement to what each verb means, then I don't see an issue. Stop seems pretty clear to me, maybe I'm just missing something. Regards, Kristoffer Sheather ---------------------------------------- From: Randy Bias <randyb(a)gogrid.com> Sent: Thursday, 7 May 2009 8:31 AM To: Tino Vazquez <tinova(a)fdi.ucm.es>, Chris Webb <chris.webb(a)elastichosts.com> Subject: Re: [occi-wg] Is OCCI the HTTP of Cloud Computing? Clone is dangerous. Please define what you mean. As far as I can tell everyone means something difference. For pass one I'd prefer to avoid verbs that aren't very specific, like 'stop'. Heck, even with stop we have differences. 'Clone' is incredibly overloaded and has lots of expectations associated with it. --Randy On 5/6/09 9:01 AM, "Tino Vazquez" wrote: > Hi everyone, > > I would like to see a clone verb (or maybe attribute, not sure about > this) for drives, also maybe as an extension. I'm thinking on > implementations sharing images using shared storage, this will allow > to use those images directly, and obviously "cloning" set to "no" will > make this image persistent automatically. What do you think? > > About the choice of format, as much as I like XML and Atom specially, > I would advocate for the "simpler is nicer" principle is there is > nothing that proves that it can do things that simple text or even > JSON (from which I can see benefits for machine and human readibility) > simply can´t, which also I haven't seen so far (Sam, please, correct > me if I am wrong). > > Regards, > > -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 > > > > On Wed, May 6, 2009 at 6:18 PM, Chris Webb > wrote: >> Alexis Richardson writes: >> >>> Chris, if you think we have a choice to make please could you describe >>> the options we have to choose from in more detail. >> >> I think Richard has just beaten me to it! However, more generally, I think >> that before we can even have these discussions about formats, we should >> confirm that we're all on the same page with regard to the semantic building >> blocks: >> >> http://forge.gridforum.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/NounsVe >> rbsAndAttributes >> >> I think Richard, Sam, Andy and I have all hacked at this page. Would anyone >> else like to comment or is there general consensus around these basic nouns, >> verbs and attributes? >> >> Cheers, >> >> Chris. >> _______________________________________________ >> 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 -- Randy Bias, VP Technology Strategy, GoGrid randyb(a)gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias _______________________________________________ occi-wg mailing list occi-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

2 1

Re: [occi-wg] On repainting the bikeshed at the 11th hour...
by Sam Johnston 08 May '09

08 May '09

Including the list this time... On 5/7/09, Sam Johnston <samj(a)samj.net> wrote: > So examples of the requisite extensibility include creating complex > storage and networking resources and importing the (large) existing > base of compute resources (in OVF or other legacy formats). It is > without doubt better to have the option and not use it than give it up > and find we need it. > > For the componentisation of implementations, it's highly unlikely that > the best architecture is to use the same platforms for everything from > controllers to monitoring to billing to security etc. in which case it > is extremely useful to be able to pass your messages around and build > them iteratively. JSON is great for [de]serialising objects in memory > but is actually more troublesome than XML for this particular use > case. > > I guess a lot of this comes down to the public vs private debate that > Ignacio captured nicely in a recent blog post. I prefer not to > differentiate and have my money on hybrid architectures. As a > potential client implementor I'd mych prefer not to have to implement > OCCi *and* vCloud^W OVF2.0 for things like that function people are > calling 'cloudbursting'. > > With XML we can be light for light users and as fat as need be for the > more demanding ones (like my enterprise clients who are primarily from > the CAC 40 - top 40 companies in France). > > FWIW I actually dislike XML as much as the next guy but I'm also very > practical and like to avoid cutting off my nose to spite my face. > > Sam on iPhone > > On 5/7/09, Mark Masterson <mmasterson(a)csc.com> wrote: >> Sam -- for the record, I find blanket assertions such as "an essential >> enterprise feature" to be problematic. I'm about as enterprisey as >> anyone >> could possibly be, and you are definitely *not* speaking on my behalf >> here. >> I've no doubt that you are speaking for someone or something that relates >> to your experience, and an alternative phrasing such as "an essential >> feature for the enterprise customers I work with" would clearly >> articulate >> that. But I"m here to tell you -- there's a large and valid population >> of >> folk who self-identify as "enterprise" who disagree with much of your >> reasoning. Here are some examples: >> >> -- "The schema is a WiP for a start, and an essential enterprise >> feature". >> >> No, it is not. In my world, we are busy trying to learn many lessons >> from >> the Web, only some of which fit within the scope of the term REST. One >> of >> the most important lessons we are trying to internalise and apply is that >> a >> priori schemas are sometimes much more trouble than they are worth. In >> that world, among other things, there are any number of examples of cases >> where I am trying to figure out how to *store my data* without an a >> priori >> schema, because that confers on me all sorts of advantages which seem to >> move me an inch or two towards the holy grail of disposable software. I >> can assure you that, in those sorts of contexts, the idea of going to >> those >> lengths, only to move data to and from those schema-less data stores via >> "standard" mechanisms that impose one of its own can provoke gales of >> (slightly bitter) laughter. >> >> -- "Our success *requires* playing nice with OVF. And SNIA. And probably >> a >> bunch of other stuff in the future" followed then by "Our spec will be >> concise anyway given how we use XML in the lightest way possible". >> >> It worries me that you may not see the contradiction lurking in those two >> statements. At best, these statements have a high probability of both >> being true only at a given point in time; one quite early in the life >> cycle >> of OCCI (which, of course, is where we are). Over time, it is *very* >> unlikely (verging on the impossible, IMO) that both statements can >> *remain* >> true. This is because the imperative underlying each of these statements >> is in direct conflict with the other -- "playing nice with others" is in >> direct conflict with "concise". We all seem to be in agreement about the >> merits of concise -- the disagreement revolves around the degree of >> "playing nice with others", and / or preparing for playing nice with >> others. I think there is a strong argument to be made for making a >> deliberate decision, at this point in the lifecycle, to *not* make >> playing >> nice with others a goal. Explicitly -- IOW, making it a non-goal. >> Instead, focus on what I thought this group was chartered to do -- the >> simplest possible common representation of what's already out there, >> working. The "others" be damned. >> >> -- "Cloud architectures are complex with many differs t extensions having >> to contribute to answers. JSON does not lend itself to this kind of thing >> so it's actually (a lot) more work for implementors" >> >> That sounds, to this "enterprise voice", like a feature, not a bug. >> Constraints are good. I like constraints. You have not yet convinced me >> that the "extensions" you refer to here are critical to the core of the >> aforementioned simplest possible common representation of what's already >> out there, working. Instead, the impression I get is that these >> extensions >> (or even the possibility of having them) serves primarily the "play nice >> with others" (non) goal. Since I don't think worrying about playing nice >> with others is a good idea, imposing a contstraint that makes it harder >> to >> do seems like a good idea to me. Helps focus on the core goal -- >> distractions fall away. In my experience, that's a design approach that, >> in turn, produces *very* robust artefacts -- ones on which it is >> subsequently relatively easy to build more stuff (to play with other, for >> example). Doing things the other way round (trying to anticipate and >> account for possible "extensions"), in my experience, too often leads to >> fragile, brittle designs. >> >> This argument, OTOH: >> >> -- "Agreed but that was before we had an almost complete spec, a rough >> reference implementation complete with mechanical transforms to the >> requested formats and the start of a HTML interface for good measure. For >> JSON we have nothing" >> >> ... is quite compelling, and in my view. And that may outweigh all other >> concerns, given the desire to hold the date. Dunno. >> >> >> >> 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 >> >

3 2

On repainting the bikeshed at the 11th hour...
by Sam Johnston 07 May '09

07 May '09

Morning all, So I've been on the road for the last half a dozen hours watching somewhat of a debate has kick off as to whether we should continue to use angle brackets (XML) to dice our data or start from scratch with curly braces (JSON). Sure it's understandable given the previous mess<http://stage.vambenepe.com/archives/700>(whereby literally dozens of different "standards" were born only to end up dead and dying) but that's essentially what it boils down to and it does feel a lot like we've taken a trip back to 2006<http://www.oreillynet.com/xml/blog/2006/12/and_the_winner_of_the_json_vs.ht…>. As one person pointed out in private it's clear there is now a good deal of backlash against "XML/SOAP/complexity" - apparently enough to consider wiping the slate clean of many years of hard (albeit thus far largely futile) work. I'm not particularly religious about the matter either way (my only vested interest is in the time I've volunteered to date and what little I have left in which to deliver results) but I do think the model is *far* more important and worthy of detailed discussion than the protocol. I've seen neither XML nor Atom impinge on anything we've needed to codify so far and once you have to reach for a library (as you do in both cases) the machines could talk pig latin to each other for all we care. The primary (and only valid IMO) objection to XML is that it tends to be abused more often than not, but zero examples of such abuse in our designs have been given and we've agreed to limit ourselves to an essentially flat structure (that must be able to be cleanly represented in alternative formats including JSON and TXT) so this is a non-issue anyway. Looking at the practicalities, XML is very mature with plenty of expertise and tools (from editors to application accelerators/firewalls) available for it while JSON is a rapidly developing new kid on the block (or is at least perceived to be by enterprise users - and perception/marketing is half of the battle). There are a lot of things we can do today with XML that we can't [and may never be able to] do with JSON such as transparently embedding supporting formats like OVF (which like it or not is going to have its time in the sun), transforming it to whatever format(s) we like in a mechanical, platform independent fashion and serialising, encrypting and signing it (for storage, queueing, etc). Atom itself is already arguably the single most successful "cloud" standard with Google using it for pretty much every public facing interface (protocol buffers are used under the covers for efficiency) and every feed on the web is using it (or something like it). There is a good deal of overlap with whatever domain specific language we might have invented ourselves (I know because I tried this before [re]discovering Atom) and it is a better fit than you might first think - feel free to go through the exercise if you need to see for yourself. In terms of the future it's also far more extensible in that adding new resources et al to a domain specific language would almost certainly require us to reconvene to create OCCI 2.0, while extensions can be safely implemented (and validated) without risk to the rest of the spec; this is not something I see as being particularly well handled with JSON now or any time soon. Furthermore, things we currently take for granted behind the scenes with XML (like being able to pass around a DOM object and have different components update it as necessary before handing the result to a renderer) are not possible unless you happen to be writing JavaScript (one of the only languages where JSON is a first class citizen rather than a third party extension). Given the current plan is to support multiple formats (even if we only actually require one of them) while maintaining the ability to move losslessly between them, there is nothing stopping us from shifting our weight to the other foot if and when JSON matures. The web never mandated the use of a single format so I don't see why we should start now (though telling implementors they must support all of them is a tall order). In terms of reaching a loose consensus I think the EH/GG guys will be satisfied if we can get clean[er] transforms, Sun ought to be happy if we follow their methodologies if not their exact protocol (e.g. single entry point, "buttons" for state changes, etc.), Google may well get on board if we make it easy for them and I'll be satisfied if I don't have to throw away a substantial base of work already completed as well as the opportunity to use the myriad existing XML/Atom/GData tools and clients (remembering a domain specific language starts with exactly zero implementations). Of course if someone *does* have a particularly strong fetish for curly braces and cares to rewrite the spec as well as a reference implementation and a bunch of transforms by next week then be my guest. Sam

5 10

Re: [occi-wg] Is OCCI the HTTP of Cloud Computing?
by Cloud Central - Kristoffer Sheather 07 May '09

07 May '09

Yup keep it as simple and constrained as possible, no point turning it into Otanic. Regards, Kristoffer Sheather ---------------------------------------- From: Randy Bias <randyb(a)gogrid.com> Sent: Thursday, 7 May 2009 8:28 AM To: Sam Johnston <samj(a)samj.net>, "occi-wg(a)ogf.org" <occi-wg(a)ogf.org> Subject: Re: [occi-wg] Is OCCI the HTTP of Cloud Computing? Amen on this one. Small and constrained. Plus use cases. That's it. --Randy On 5/6/09 7:04 AM, "Sam Johnston" <samj(a)samj.net> wrote: In general, the more focused and narrow a modeling effort is, the more successful it seems to be (with OVF as the most focused of the list and CML as the other extreme). -- Randy Bias, VP Technology Strategy, GoGrid randyb(a)gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias

1 0

Re: [occi-wg] Is OCCI the HTTP of Cloud Computing?
by Cloud Central - Kristoffer Sheather 07 May '09

07 May '09

Hi Richard, As a developer coming from an enterprise IT background, .NET in particular, I support an XML rendering of the OCCI protocol. Whether it should be atom based remains to be seen IMO. Personally I prefer plain old XML + XML schema. I think that we need to focus on the model itself primarily, ensuring its kept as abstract as possible whilst still being specific enough to meet requirements. Once we have the model defined, then we can focus more on the rendering from the model to the data formats. I do agree that whatever route we take, feature support by each protocol rendering should be lossless, or as lossless as possible. There should be no first and second class citizens here. Regards, Kristoffer Sheather ---------------------------------------- From: Richard Davies <richard(a)daviesmail.org> Sent: Thursday, 7 May 2009 12:56 AM To: Sam Johnston <samj(a)samj.net> Subject: Re: [occi-wg] Is OCCI the HTTP of Cloud Computing? [from discussion Ben Black] > XML drags along an awful lot of baggage, which has resulted in many folks > using lighter-weight formats like JSON. ATOM, in turns, lards still more > baggage into the mix, again ... > JSON has similarly moved well beyond its origins as something used by > Javascript (see CouchDB for a great example). Finally, it is a simple, > text-based system, far simpler than XML, and I have recent, painful > experience in working in JSON and XML simultaneously for systems > management. A man after my own heart ;-) Seriously, I think the point here is that the Atom XML vs. simple JSON/TXT discussion is a typical unresolvable programmers' religious war. To caricature: - One camp will always believe that Atom XML is more flexible, extensible and Enterprise-ready, whilst being "simple enough". - The other camp will always believe that very basic JSON/TXT formats are much simpler, lower baggage and "flexible/extensible enough". OCCI will be used by programmers from both camps, so we need to meet both needs. Luckily on this mailing list we have Sam as a strong advocate of the first camp, and ElasticHosts as a strong advocate of the second ;-) As I have said before, my aim is that the XML, JSON and TXT formats should all share the same nouns, verbs and attributes, and should also be automatically translatable into each other, but beyond that each should be well designed in their own right. ElasticHosts will continue to fight strongly for the second camp in the JSON and TXT format, whilst deferring on most issues of taste in the XML format. I'd like to see members of the first camp fighting strongly in the XML format, but deferring on most issues of taste in the JSON and TXT formats. Cheers, Richard. _______________________________________________ occi-wg mailing list occi-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

1 0

OCCI-wg concall Wednesday May, 6 - 5pm CET
by Thijs Metsch 05 May '09

05 May '09

Hi @all, It is time for our second OCCI-wg weekly concall. I would like to invite you to join Wednesday May 6, 2009 (tomorrow) @ 5pm CET. The time in your timezone can be found on our Wiki page: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… There is also a link to a meeting planner tool. The dates and times for all upcoming concalls will always be placed an update on that page. The agenda is currently set to: 1. Action items from last week 2. OGF preparation 3. Have a look at requirements 4. API discussion You can add topics to the agenda at our meeting minutes page: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Concall20090… The passcode and the dial-in details are also in the wiki: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/Teleconferen… 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

progress?
by Alexis Richardson 05 May '09

05 May '09

Hi guys, Any chance we shall see some verbs on here by Wednesday? http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/APIDesign alexis

3 4