[Capi-bof] Charter - last call for changes

[Sam Johnston]

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<http://en.wikipedia.org/wiki/CAPI>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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/capi-bof/attachments/20090324/11c7f99d/attachment.html