[Capi-bof] Charter - last call for changes

[Thijs Metsch]

+1 will use OCCI as new group abbreviation...

On Tue, 2009-03-24 at 11:29 +0000, Alexis Richardson wrote:
> Further, I think that for marketing/branding reasons having a general
> name "open cloud computing" is good - easier for the max # of folks to
> buy into.  Putting INTERFACE at the end makes it clear this is about
> delivering a thing - an interface.
> 
> I agree with Sam that focussing on infra is good.  It is vital to
> choose an approach that can succeed.  Success breeds buy-in, traction
> and more success. Let's start simple -- so my suggestion is to put
> that "infra focus" into the initial "mission statement" of the group.
> Then, as the industry evolves, so will the mission statement.
> 
> 
> 
> On Tue, Mar 24, 2009 at 11:23 AM, Alexis Richardson
> <alexis.richardson at gmail.com> wrote:
> > OCCI is easier to pronouce and remember the spelling of ;-)
> >
> >
> > On Tue, Mar 24, 2009 at 11:18 AM, Thijs Metsch <Thijs.Metsch at sun.com> wrote:
> >>
> >> Hi Sam,
> >>
> >> Thanks a lot for your reply! see the inline comments :-)
> >>
> >> On Tue, 2009-03-24 at 10:52 +0100, Sam Johnston wrote:
> >>> 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.
> >>
> >> Okay we can shift it out till monday evening 5pm CET.
> >>
> >>>  - 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?
> >>
> >> I like Alexis's proposal of OCCI or from you OCII. Any other thoughts?
> >>
> >>>  - 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.
> >>
> >> I'll try to take that into account and rewrite the parts.
> >>
> >>>  - 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.
> >>
> >> Any ideas on howto proceed here? Drop it? Point to existing solutions,
> >> Take it in account?
> >>
> >>> 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).
> >>
> >> that would be nice :-)
> >>
> >> All the best,
> >>
> >> -Thijs
> >>
> >>> 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
> >> --
> >> 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
> >>
> >
-- 
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