[Capi-bof] Charter - last call for changes

[Sam Johnston]

Alexis,

In fact the reverse is true - for a physical machine many of the variables
(storage, network configuration, RAM, CPU, etc.) are set in stone. All you
need to do is feed it an image and then the "governor" (for want of a better
term) will take care of loading it up and powering on the machine.

That is to say, catering for this requirement need not in fact introduce
more complexity into the API. What it will do though is avoid the risk of
the API being quickly obsoleted while also avoid excluding certain types of
provider.

To give specific examples, on the physical machine side you've got providers
like dedibox.fr (who provision standard configuration machines on a large
scale for €29.99/month) and on the "slice" side you've got providers like
Mosso Sites who are already offering the service I spoke of before, starting
at 1.5c/hr ($10/month) for what is almost certainly some flavour of VPS.

It's not surprising given Thijs' and Ignacios' work with Sun and OpenNebula
respectively that everything should look like a VM (when you're a hammer
everything looks like a nail - no offense intended) but it is crystal clear
to me that the benefit of going general on this point far outweighs the
cost.

Sam

On Tue, Mar 24, 2009 at 3:07 PM, Alexis Richardson <
alexis.richardson at gmail.com> wrote:

> If the API for physical machines is a superset of that for VMs, then
> maybe start with the latter, then take stock and grow from that
> base...?
>
>
> On Tue, Mar 24, 2009 at 1:40 PM, Sam Johnston <samj at samj.net> wrote:
> > On 3/24/09, Thijs Metsch <Thijs.Metsch at sun.com> wrote:
> >>
> >> I'm currently rewriting it using "resource virtualization" as 'the' term
> >> - which basically means virtual machines. Not more an not less...
> >
> > If Amazon (or a competitor) were to offer vservers tomorrow for 1c/hr
> > instead of 10c/hr, how many people would migrate? I know I'd move my
> > DNS secondaries there in a heartbeat and it's just a matter of time
> > until such services appear.
> >
> > VMs are insufficiently granular and there is no reason to restrict the
> > API like this-the complexity will be concealed behind it anyway and
> > the user doesn't [need to] care. Let's not forget that the vast
> > majority of cloud computing today is done on bare metal (eg google,
> > Salesforce) too.
> >
> > It was not without significant consideration that I came up with the
> > container/workload terminology and Andy at least agreed that we need
> > to cater for this requirement. Do you have any thoughts Alexis? Anyone
> > else?
> >
> > Sam on iPhone
> >
> >> all the best,
> >>
> >> -Thijs
> >>
> >> On Tue, 2009-03-24 at 13:01 +0000, David Snelling wrote:
> >>> Folks,
> >>>
> >>> On 24 Mar 2009, at 11:18, Thijs Metsch wrote:
> >>>
> >>> >> - 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.
> >>>
> >>> My advice here, as I said on the call, is to stay narrow (e.g. VMs
> >>> only). Including physical machines is all about DC management, and if
> >>> you include concepts like "workload" you are starting the ocean
> >>> boiler. You don't want to go there.
> >>>
> >>>
> >>> Take care:
> >>>
> >>>      Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
> >>>      Fujitsu Laboratories of Europe Limited
> >>>      Hayes Park Central
> >>>      Hayes End Road
> >>>      Hayes, Middlesex  UB4 8FE
> >>>      Reg. No. 4153469
> >>>
> >>>      +44-7590-293439 (Mobile)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ______________________________________________________________________
> >>>
> >>>  Fujitsu Laboratories of Europe Limited
> >>>  Hayes Park Central, Hayes End Road, Hayes, Middlesex, UB4 8FE
> >>>  Registered No. 4153469
> >>>
> >>>  This e-mail and any attachments are for the sole use of addressee(s)
> and
> >>>  may contain information which is privileged and confidential.
> >>> Unauthorised
> >>>  use or copying for disclosure is strictly prohibited. The fact that
> this
> >>>  e-mail has been scanned by Trendmicro Interscan and McAfee Groupshield
> >>> does
> >>>  not guarantee that it has not been intercepted or amended nor that it
> is
> >>>  virus-free.
> >> --
> >> 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/2ac8883e/attachment-0001.html