[Capi-bof] Charter - last call for changes

Tue Mar 24 10:58:51 CDT 2009

Andy,

The simple solution to this is to, for each interface (assuming there are
any - batch jobs may well not have any connectivity remember) specify the
[virtual] network segment that it should be connected to - the default being
"internet".

For our purposes that identifier could just be a text string ("internal",
"dmz", "secure", etc.) but it could also have some inherent meaning (eg
"vlan-197" for 802.1q tagged VLAN #197). Ditto for storage (e.g. "bertha",
"zfs-tank-27", "/dev/sda1", etc.).

The key thing is that the details would be left to the underlying fabric.

Sam

On Tue, Mar 24, 2009 at 2:02 PM, Edmonds, AndrewX <andrewx.edmonds at intel.com
> wrote:

> At least keep it to a minimum - in the case of a multi-tier application
> provisioning we would need to specify which VM is to be exposed publically
> and which ones to keep private as such this requires some amount of network
> configuration. Pointing to storage mount points should be perfectly
> sufficient for now :-)
>
> Andy
>
> -----Original Message-----
> From: Sam Johnston [mailto:samj at samj.net]
> Sent: 24 March 2009 12:53
> To: Edmonds, AndrewX
> Cc: Alexis Richardson; Thijs Metsch; capi-bof
> Subject: Re: [Capi-bof] Charter - last call for changes
>
> On 3/24/09, Edmonds, AndrewX <andrewx.edmonds at intel.com> wrote:
> > Agreed - in fact the point to remain acutely focused was made by David
> > Snelling (correct if wrong) yesterday in the teleconf.
>
> Can we also agree then to limit our endeavour to the specification of
> network interfaces, mount points, etc., leaving the details as to how
> it's all wired up to the underlying fabric?
>
> Sam
>
>
>
> > -----Original Message-----
> > From: capi-bof-bounces at ogf.org [mailto:capi-bof-bounces at ogf.org] On
> Behalf
> > Of Alexis Richardson
> > Sent: 24 March 2009 11:29
> > To: Thijs Metsch
> > Cc: capi-bof
> > Subject: Re: [Capi-bof] Charter - last call for changes
> >
> > 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
> >>>
> >>
> > _______________________________________________
> > 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/capi-bof/attachments/20090324/677d3d99/attachment-0001.html 