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

Wed Mar 25 10:58:12 CDT 2009

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
>
>