[Capi-bof] Charter - last call for changes

[Alexis Richardson]

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
>