[Capi-bof] Charter - last call for changes

[Alexis Richardson]

How about Open Cloud Computing Interface --- OCCI.

It seems reasonable untainted:
http://www.google.com/search?hl=en&client=safari&rls=en&q=occi&btnG=Search

a


2009/3/24 Sam Johnston <samj at samj.net>:
> Thanks Thijs.
>
> I think we've still got a bit of work to do on the charter so perhaps we can
> finalise for Friday, pushing the last call out to Monday/Tuesday for
> Wednesday's steering committee meeting? Otherwise we've essentially got
> until tomorrow to get it tightened up.
>
>  - The group name is important (e.g. for SEO) and CAPI clashes not only with
> the ISDN stuff but also Microsoft's Cryptography API and a bunch of
> commercial interests. It should also be obvious what we're doing - "Cloud
> API" is meaningless and IaaS-API is too "aas"y. CIA has obvious problems so
> how about CIAPI, CI-API or CCI-API?
>
>  - You're the chair and Ignacio is the co-chair if I understood well from
> David yesterday
>
>  - The focus is still on virtual machines when there are actually three
> types of "containers" we're wanting to control:
>  * Physical machines
>  * Virtual machines
>  * Lightweight virtual machines (zones, vservers, slices, etc.)
> I would suggest adopting the term "workload" in place of "virtual machine"
> (which could come in the form of a physical server image, virtual machine,
> tgz chroot, etc.) and using "container" in place of hypervisor, server,
> zone, chroot, etc.
>
>  - Networking is a bottomless pit - I was thinking about this yesterday
> after the call and given work F5, VMware, Cisco and others are doing in this
> area I think it may not be necessary for us to get too involved. Having
> worked on the Netscaler APIs at Citrix I can assure you there is more to
> this area than meets the eye. All a VM needs is a connection to the outside
> world - it doesn't care about firewalling, load balancing, failover, etc.
>
>  - Ditto for storage - a workload just (optionally) needs pool(s) of storage
> to be mounted for it... it doesn't care whether it's RAID etc.
>
>  - Arbitrary metrics like network latency and bandwidth, storage size and
> durability, CPU cores and speed, uptime, SLAs, etc. may need to be
> offered/requested/required, especially if this API is eventually to be used
> in a cloud computing exchange and/or for deployment decisions, though these
> metrics need not necessarily be well defined by us.
>
>  - Define "Cloud Infrastructure" and use it consistently throughout. Mention
> it's aka "Infrastructure as a Service (IaaS)" but then drop the "aas".
>
>  - Drop "Grid developers...private cloud sites" sentence, or at least
> generalise it: "Providers to deliver accessible infrastructure to end-users"
>  - Generalise "Service management platforms...automated elasticity rules" to
> cover Independent Software Vendors and arbitrary management applications.
>  - Clarify cloud computing interoperability.
>
> I would personally like to see a tight, clean API developed which is easy to
> consume on the user side (think curl/wget) and easy to implement on the
> provider side (minimal calls, as close as possible to the "consensus" of
> what exists today).
>
> I should hope that we can get something like this churned out in short order
> (even to have an implementable draft for the next meeting) and have set
> aside some time to assist.
>
> Sam
>
> 2009/3/24 Thijs Metsch <Thijs.Metsch at sun.com>
>>
>> hi @all,
>>
>> find attached the current version of the charter. Please send in all
>> your comments till Friday (03/27/09 - 3pm CET). I would like to finalize
>> it by then and send it to the OGF steering committee - they need to
>> approve it very soon, wo we can finally get an official working group in
>> OGF :-)
>>
>> Thanks for the help,
>>
>> -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 at sun.com
>> D-93049 Regensburg                  http://www.sun.com
>>
>> _______________________________________________
>> Capi-bof mailing list
>> Capi-bof at ogf.org
>> http://www.ogf.org/mailman/listinfo/capi-bof
>>
>
>
> _______________________________________________
> Capi-bof mailing list
> Capi-bof at ogf.org
> http://www.ogf.org/mailman/listinfo/capi-bof
>
>