[Capi-bof] Charter for Open Cloud Computing Interface (OCCI) Working Group

Wed Mar 25 10:53:24 CDT 2009

+1
--
Ignacio M. Llorente, Full Professor (Catedratico): web http://dsa-research.org/llorente 
  and blog http://imllorente.dsa-research.org/
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 25/03/2009, at 16:48, Edmonds, AndrewX wrote:

> There should be no speak of hypervisors in the charter, IMHO. It’s  
> an internal management consideration and we should be very aware of  
> keeping concerns separate.
> The OCCI should be concerned with is the lifecycle management of  
> infrastructural resource(s) mediated through its interface. So with  
> respect to starting, stopping and restartingtype actions, these  
> should be methods that are available to interact with one or a  
> collections of resource(s). It’s here where the Sun Cloud API has  
> things spot on – it only deals with virtual machines and logical  
> groupings of them and the actions (methods) that are appropriate for  
> each entity (VM, Cluster, VDC).
>
> Andy
>
> From: Sam Johnston [mailto:samj at samj.net]
> Sent: 25 March 2009 15:35
> To: Alexis Richardson
> Cc: Edmonds, AndrewX; capi-bof at ogf.org
> Subject: Re: [Capi-bof] Charter for Open Cloud Computing Interface  
> (OCCI) Working Group
>
> On Wed, Mar 25, 2009 at 4:22 PM, Alexis Richardson <alexis.richardson at gmail.com 
> > wrote:
> On REST can we say "eg RESTful"
>
> Sorry, that was meant to be an e.g. anyway - so as to allow readers  
> without the benefit of context to understand what we're talking about.
>
> The virtual data center requirement should probably be explicitly  
> stated, and I think we'll learn a lot from their example (the Sun  
> Cloud APIs may well make a good starting point for us so if we're  
> going to align ourselves with anyone then it might want to be them  
> given this is exactly what Q-Layer's about). OVF supports  
> collections of systems too.
>
> Anyway a lot of this functionality can be implemented with simple  
> tagging (ala the network and storage interface suggestions I made  
> earlier) - for example we can tag servers "rack1" or "web-cluster"  
> and then primitives like start, stop and restart can operate over  
> tagged groups and a priority field can make sure things happen in  
> the right order.
>
> The management of hypervisors would be limited to things like  
> reservations, starting, stopping and restarting, unless you've got  
> another idea.
>
> Sam
> 2009/3/25 Edmonds, AndrewX <andrewx.edmonds at intel.com>:
> > Inlined some questions…
> >
> > From: capi-bof-bounces at ogf.org [mailto:capi-bof-bounces at ogf.org]  
> On Behalf
> > Of samj at samj.net
> > Sent: 25 March 2009 14:51
> > To: capi-bof at ogf.org; samj at samj.net
> > Subject: [Capi-bof] Charter for Open Cloud Computing Interface  
> (OCCI)
> > Working Group
> >
> > <snip>
> >
> > Group summary:
> >
> > Cloud computing can be categorized into three main areas (Cloud
> > Infrastructure or "IaaS", Cloud Platforms or "PaaS" and Cloud  
> Software or
> > "SaaS") which all involve the on-demand delivery of computing  
> resources.
> > There are a growing number of infrastructure (IaaS) providers  
> offering
> > elastic capacity, whereby server "instances" are executed in their
> > proprietary infrastructure and billed on a utility computing basis
> > (typically virtual machines on a per instance per hour basis).  
> There are
> > also a number of commercial and open source products which seek to  
> replicate
> > this functionality in-house while exposing compatible interfaces  
> so as
> > "hybrid cloud" operating environments can be created.
> >
> > [AE: ] It might be useful to include the idea of not only  
> provisioning
> > server instances but data centre instances, which are simply a  
> collection of
> > server instances joined by an abstract network configuration. One  
> server in
> > my view does not equate to infrastructure J
> >
> > The Open Cloud Computing Interface (OCCI) will deliver a common  
> interface
> > for remote management of cloud computing infrastructure, allowing  
> for the
> > development of interoperable tools for common tasks including  
> deployment,
> > autonomic scaling and monitoring. The scope of the specification  
> will be all
> > high level functionality required for the life-cycle management of  
> workloads
> > (e.g. virtual machines) and containers (e.g. hypervisors)  
> supporting service
> > elasticity.
> >
> > [AE: ] Does this imply that the management of hypervisors will be  
> actionable
> > via the proposed interface?
> >
> > <snip>
> >
> > The resulting interface will be clear and concise, standards based  
> (RESTful
> > HTTP) and thus easily implemented and consumed. As it will be  
> largely
> > derived from examination of existing implementations, it can be  
> viewed as a
> > "consensus" of the innovation to date.
> >
> > [AE: ] Need we specify a REST approach here at this stage?
> >
> > Goals/deliverables:
> > The primary deliverable is a technical specification of the Open  
> Cloud
> > Computing Interface (OCCI) in one or more open formats (e.g.  
> DocBook) and
> > under an open license (e.g. Creative Commons Attribution  
> ShareAlike 3.0
> > Unported).
> >
> > Other deliverables that may be created in the process include use  
> cases,
> > surveys, presentations, user manuals, implementator guides, etc.
> >
> > Reference implementation(s) are specifically excluded, as are  
> details
> > relating to supporting infrastructure (such as storage and network  
> hardware
> > configuration).
> >
> > Timetable:
> >
> > OGF25
> >
> > March 2-6 2009
> >
> > Cloud Computing API BoF Session
> >
> > OGF26
> >
> > May 26-29 2009
> >
> > Overview & Rough API Presentations
> >
> > OGF27
> >
> > October 12-16 2009
> >
> > Draft API Presentation
> >
> > OGF28
> >
> > TBA
> >
> > Final API Presentation
> >
> > Exit strategy:
> > The work of this group will be deemed complete when all the  
> documents are
> > completed.
> >
> > Questions:
> >
> > Is the scope of the proposed group sufficiently focused?
> > Yes, the group will deliver an API addressing a confined set of  
> requirements
> > for Cloud Infrastructure (IaaS)
> > Are the topics that the group plans to address clear and relevant  
> for the
> > Grid research, development, industrial, implementation, and/or  
> application
> > user community?
> > Yes, many grid deployments today are related to cloud computing  
> offerings.
> > Delivery of an API is beneficial both to grid providers and their  
> users.
> > Grid and cloud are complementary, with the vast majority of cloud  
> offerings
> > today being powered by grid infrastructures.
> > Will the formation of the group foster (consensus-based) work that  
> would not
> > be done otherwise?
> > Yes, efforts to date have thus far failed to deliver an API  
> suitable for
> > widespread adoption. Within OGF this initiative is unique and  
> forms a great
> > opportunity to quickly create a standard for research and industry.
> > Do the group's activities overlap inappropriately with those of  
> another OGF
> > group or to a group active in another organization such as IETF or  
> W3C?
> > No, existing efforts to date have been conducted by commercial  
> entities
> > (giving rise to governance concerns) or by ad-hoc standards  
> groups. The
> > specification will complement standard(s) from other groups (e.g.  
> HTTP,
> > OAuth, OVF, SSL/TLS).
> > Are there sufficient interest and expertise in the group's topic,  
> with at
> > least several people willing to expend the effort that is likely  
> to produce
> > significant results over time?
> > Yes, the group already has sufficient active members to deliver the
> > specification including representatives from academia, industry and
> > consumers. There is a significant body of work already completed  
> from which
> > a "consensus" can be derived. Research projects including SLA at SOI,
> > OpenNebula, RESERVOIR and Nimbus have also stated an interest and  
> some have
> > active representation already.
> > Does a base of interested consumers (e.g., application developers,  
> Grid
> > system implementers, industry partners, end-users) appear to exist  
> for the
> > planned work?
> > Yes, there is already a thriving ecosystem of cloud computing  
> providers and
> > consumers who could benefit from this work.
> > Does the OGF have a reasonable role to play in the determination  
> of the
> > technology?
> > Yes, the OGF determines standards relating to grid computing. Most  
> cloud
> > computing deployments today are based on grid infrastructures and  
> the two
> > fields are complementary. Furthermore, most actors in the grid  
> space are
> > also active in cloud computing.
> >
> > Group status:
> > BoF
> >
> > Public description (for print & web):
> > "Group summary" above.
> >
> > -------------------------------------------------------------
> > 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.
> >
> > _______________________________________________
> > Capi-bof mailing list
> > Capi-bof at ogf.org
> > http://www.ogf.org/mailman/listinfo/capi-bof
> >
> >
>
> -------------------------------------------------------------
> 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.
> _______________________________________________
> Capi-bof mailing list
> Capi-bof at ogf.org
> http://www.ogf.org/mailman/listinfo/capi-bof