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

Wed Mar 25 10:59:48 CDT 2009

No problem in mentioning so long as there's no association with OCCI and the management of hypervisors :-)

-----Original Message-----
From: Alexis Richardson [mailto:alexis.richardson at gmail.com]
Sent: 25 March 2009 15:58
To: Ignacio Martin Llorente
Cc: Edmonds, AndrewX; Sam Johnston; capi-bof at ogf.org
Subject: Re: [Capi-bof] Charter for Open Cloud Computing Interface (OCCI) Working Group

I think this makes sense, but Sam's text did say "eg hypervisors" as a
way of describing what a container might be.

Andrew - is that a problem?

On Wed, Mar 25, 2009 at 3:53 PM, Ignacio Martin Llorente
<llorente at dacya.ucm.es> wrote:
> +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
>
>
-------------------------------------------------------------
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.