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

OCCI MC - State Machine Diagram
by Sam Johnston 14 May '09

14 May '09

Afternoon all, I have created a diagram (attached) of what I think the absolute minimum core states need to be... essentially boiling them down to "STOPPED" and "ACTIVE" with "START" and "STOP" being the only requisite actuators. Transitional "STOPPING" and "STARTING" states are optional. I believe states should be completely unambiguous so I don't particularly like the DMTF model ("stopped" and "active" machines are also "defined" but this is a separate state) and that also rules out vague terminology like "inactive" (which could mean both "stopped" and "suspended"). I've got an optional RESTART actuator which takes you from "ACTIVE" to "STARTING" as well as an optional "SUSPEND" and "RESUME" cycle which takes you via the transitional "SUSPENDING" and "RESUMING" states between "ACTIVE" and "SUSPENDED". DMTF have another "paused' state but I wonder whether this needs to be a state in its own right or if it's an attribute of "suspended". That's a rhetorical question - we could spend all week discussing nuances but for now I want to make sure we agree on the absolutely minimalist core functionality. Other states can be added via a live registry which we can pre-populate with a view to guiding innovation without stifling it. This has been uploaded to the wiki: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/StateModel Sam

17 89

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

The Open Cloud is Coming
by Randy Bias 29 Apr '09

29 Apr '09

Had to quiet some of the nay-sayers on how closed¹ the cloud is. So I posted this blog entry that some of you may have already seen. Hopefully it helps push our efforts here forward: http://neotactics.com/blog/technology/the-open-cloud-is-coming Thanks, --Randy -- Randy Bias, VP Technology Strategy, GoGrid randyb(a)gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias

5 5

Call Followup
by Randy Bias 29 Apr '09

29 Apr '09

Just want to clarify re: storage that we don¹t need it in the initial draft, but are keen to have a standard around some aspects of it. If I recall correctly we drew the line on storage saying that the core API functionality would allow managing it at the infrastructure (disk, mount, etc.) level, but not necessarily at the file/object level. We¹ll also need the latter, which is what I believe the SNIA folks are working on. I can¹t recall the particular working group. Mark Carlson, do you know which one it is? Anyway, in order of priority my desired list of deliverables looks something like this: 1) Clean core API + extensibility delivered ASAP (preferably by end of June) 2) Storage mgmt extensions for block devices and mount points (end of July) 3) File/object based extensions to allowing send/receive and arbitrary URLs for retrieval of any given file/object (end of August) Just putting my desired scenario and objectives here. I realize we might not be able to achieve all of these in this time frame. I also realize that SNIA probably is the best owner for 3. I¹m eager for them to join us on the next call. --Randy -- Randy Bias, VP Technology Strategy, GoGrid randyb(a)gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias

2 1

OCCI-wg concall Wednesday 29, 2009 - 5pm CET
by Thijs Metsch 29 Apr '09

29 Apr '09

Hi @all, It is time for our second OCCI-wg weekly concall. I would like to invite you to join Wednesday 29, 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. Use cases and Requirements discussion 2. Technical 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 1

OGF officially launches working group to create an API for cloud infrastructure services
by IGNACIO MARTIN LLORENTE 28 Apr '09

28 Apr '09

More details at http://www.ogf.org/News/news.php?id=132 Cheers, Ignacio

1 0

New use case based on RESERVOIR's Service Manager
by Luis Rodero-Merino 28 Apr '09

28 Apr '09

Hello all, We have just added a new use case that tries to summarize the requirements from the point of view of Reservoir's Service Manager. As many of you know, Reservoir is an European Union FP7 funded project, that deals with Cloud Computing related technologies at different levels from virtualization to services management. This use case introduces a set of requirements that are based on what the Reservoir's Service Manager component (which controls the lifecycle of services deployed in the Cloud) demands from the underlying Cloud infrastructure. The use case can be found at: http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/ServiceManag… Regards, Luis Rodero-Merino -- ----------------- Luis Rodero, PhD. Junior Researcher @ Telefónica I+D

1 0

vCloud architecture diagrams
by Wes Felter 27 Apr '09

27 Apr '09

VMware has revealed few technical details about vCloud, but I found this public presentation containing some interesting diagrams starting on pages 50 and 76. Overall, the concepts appear similar to the work going on in OCCI. http://forum.stanford.edu/events/2009Plenary/Orran%20Kriegar.pdf The bullets "Researchers can replace any part of the service." and "Researchers can replace the entire implementation and clone the API" also caught my eye. Wes Felter - wesley(a)felter.org

7 9

FYI: Locator/Identifier Separation Protocol
by Edmonds, AndrewX 24 Apr '09

24 Apr '09

Posted over in the cloud forum group by Reuven Cohen "The IETF has announced the formation of an official LISP (Locator/Identifier Separation Protocol) working group. See > http://www.ietf.org/mail-archive/web/lisp/current/msg00413.html Why is LISP important for cloud interoperability? * As an end-point addressing identifier to uniquely identify a network interface within its local network addressing context * As a locator for routing purposes, to identify where a network interface is located within a larger routing context * Requires no changes to end-systems or to most routers. * As an incrementally deployable protocol. * Particularly useful for VM centric application portability" Andy Edmonds skype: andy.edmonds tweets: @dizz tel: +353 (0)1 6069232 IT Research - IT Innovation Centre - Intel Ireland Ltd. 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.

1 0