[Capi-bof] Charter - last call for changes

[Alexis Richardson]

Is Mosso's API in your list?

And can we call it the Governator ;-)


On Tue, Mar 24, 2009 at 3:24 PM, Sam Johnston <samj at samj.net> wrote:
> 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
>> >
>
>