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

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

Extraction of requirements
by Ignacio Martin Llorente 01 May '09

01 May '09

Hi, We are going to start with the evaluation of the submitted use cases. I am planing to create a table summarizing requirements for the different use cases with the following entries: A. Functional Requirements VM Description VM Management Network Management Image Management B. Non-functional Requirements Security Quality of Service Others Any suggestion? 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

7 16

Re: [occi-wg] Extraction of requirements
by Cloud Central - Kristoffer Sheather 01 May '09

01 May '09

Hi Andy, Another placement rule for VM's might be: don't place my VM's on a single physical host server - to ensure that a virtual cluster the customer defines isn't killed by the failure of a single host server. Adding additional hardware resources for VM's will only be possible for those VM's running operating systems that support hot add of additional hardware. OS's that don't support hot adding of hardware will require a reboot. A VM that is receiving a certain share of a host CPU could however be granted more shares without any reconfiguration of the guest VM without any issues. Regards, -- Kristoffer Sheather Cloud Central Pty Ltd ---------------------------------------- From: "Edmonds, AndrewX" <andrewx.edmonds(a)intel.com> Sent: 30 April 2009 19:53 To: Ignacio Martin Llorente <llorente(a)dacya.ucm.es> Subject: Re: [occi-wg] Extraction of requirements Hey Ignacio :-), Examples of elasticity: For a machine: - Set memory utilisation to 512MB but allow to grow to 1GB if demand exceeds minimum capacity - Set number of CPUs to 2 but allow to grow to 4 if demand exceeds minimum capacity - Set disk space to 5GB but allow to grow to 10GB if demand exceeds minimum capacity - Set network bandwidth to 10GB/s but allow to grow to 20GB/s if demand exceeds minimum capacity To each of these a policy can be applied that either seeks to minimise resource consumption (shrink; active) or the counter maintain current (keep expanded; passive) for a set period. There are also some examples of OVF ranges in section 8.4 of [1]. Regarding the state of current providers & vertical scaling; from what I seen so far are fix virtual hardware specifications offered to clients that cannot grow according to specified simple rules. The closest that I've seen is where a provider offers "burstable" capacity but this non-functional attribute (from the user's point of view) is not as fine-grained as the example rules above. If we take the example of Amazon EC2, to move from a small instance to a large instance means a re-provisioning AFAIK. Does anyone here have any examples where this is not the case? As for placement constraints, I would imagine, just like what you said, that many of such non-functional properties like this would be hidden from the users of an IaaS interface and are mostly internal concerns of providers. Again as you stated in your previous mail, the only "placement" constraint that would be of relevance to users would be geographic location of provisioned resources (legal compliance or performance considerations etc). Andy [1] http://www.dmtf.org/standards/published_documents/DSP0243_1.0.0.pdf -----Original Message----- From: Ignacio Martin Llorente [mailto:llorente@dacya.ucm.es] Sent: 30 April 2009 10:11 To: Edmonds, AndrewX Cc: Krishna Sankar (ksankar); occi-wg(a)ogf.org Subject: Re: [occi-wg] Extraction of requirements Hi > I would prefer to see _infrastructure_ elasticity rules included as > they are directly related to a provisioning request (also helps a > provider do some up front resource optimisation). OVF also follows > this approach with their notion of "ranges". It makes sense as > pushing infrastructure elasticity rule management off to another > service only introduces another dependency that has to be managed/ > tracked. Placing elasticity rules upfront and in the context of the > infrastructure request also aids in the creation of guarantees of > infrastructure so clients requesting infrastructure can further rely > on the offers given by providers (risk mitigation). Could you given an example of an infrastructure elasticity rule?, are they placement constraints? > I do however see that the elasticity of services (or scalability) > running on infrastructure should be managed by a service management > layer, possibly external, for example scalr - where it has > application specific scaling strategies to deal with horizontal > scaling based on infrastructural metrics. > > Speaking of horizontal scaling brings to mind vertical scaling. > Vertical scaling is what infrastructure should support via > elasticity. Horizontal scaling is what should and is be supported by > the likes of rightscale and scalr. This makes for a very clear and > clean separation of concerns and lessening of dependencies. By > supporting the two we have in effect diagonal scaling. All scaling > types can also, and in the case of cloud, be virtual and so by > virtualisation's theoretical nature, infinite in capacity. > > With respect to infrastructure placement rules/policies, these > approaches can still exist with vertical scaling and the clues > (elasticity rules in this case) supplied at provisioning time, can, > support runtime optimisation to some degrees. > > So what I suggest is differentiation between scaling on the cloud; > horizontal and vertical, where horizontal remains in the domain of > PaaS and vertical in the domain of IaaS. Agreed, in fact, if I am not wrong, infrastructure providers supports vertical scaling, this is support for dynamic changing the resource attributes of a running VM Regards > > Andy > > -----Original Message----- > From: occi-wg-bounces(a)ogf.org [mailto:occi-wg-bounces@ogf.org] On > Behalf Of Ignacio Martin Llorente > Sent: 30 April 2009 08:36 > To: Krishna Sankar (ksankar) > Cc: occi-wg(a)ogf.org > Subject: Re: [occi-wg] Extraction of requirements > > Hi, > > In my view: > > - SERVICE ELASTICITY RULES are implemented by the service management > layer on top of the infrastructure clouds. That is the case of > RightScale or the RESERVOIR Service Manager (Nephele by Telefonica I > +D), service management tools grow or shrink the service using the > Cloud API to meet given SLOs. See use case http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/ServiceManag… > by Telefonica I+D (RESERVOIR) > > - INFRASTRUCTURE PLACEMENT RULES/POLICIES, such as load balancing or > VM consolidation, are executed internally by the cloud provider in > order to optimize a given metric, and are not exposed to end users. > The user can only define placement constraints as attributes in the VM > definition, for example to specify a geographical location. > > Regarding storage management, I understand that is related to image > management, that is the functionality that must be delivered for > enabling cloud infrastructure services (methods to register, upload, > update and download disk images). > > Cheers > -- > 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 > > > > > > > > > > > On 30/04/2009, at 2:15, Krishna Sankar (ksankar) wrote: > >> What about Elasticity rules, adjacency rules, processing rules et >> al ? >> Or Should we generically have a policy category ? >> >> Also storage management might be another one. >> >> Cheers >> >> >> |-----Original Message----- >> |From: occi-wg-bounces(a)ogf.org [mailto:occi-wg-bounces@ogf.org] On >> Behalf >> |Of Ignacio Martin Llorente >> |Sent: Wednesday, April 29, 2009 9:33 AM >> |To: occi-wg(a)ogf.org >> |Subject: [occi-wg] Extraction of requirements >> | >> |Hi, >> | >> |We are going to start with the evaluation of the submitted use >> cases. >> |I am planing to create a table summarizing requirements for the >> |different use cases with the following entries: >> | >> |A. Functional Requirements >> |VM Description >> |VM Management >> |Network Management >> |Image Management >> | >> |B. Non-functional Requirements >> |Security >> |Quality of Service >> |Others >> | >> |Any suggestion? >> | >> |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 >> | >> | >> | >> | >> | >> | >> | >> | >> | >> | >> |_______________________________________________ >> |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. ------------------------------------------------------------- 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

2 1