[Capi-bof] Charter - last call for changes

[David Snelling]

Folks,

Remember that the key point of a standard in interoperability. If we  
do VM only - that WILL be useful for interoperability. However, the  
hardware resources will only really be useful INSIDE the cloud and  
therefore useful, but only in isolation where interoperability is not  
a motivator. Exposing real hardware outside the cloud defeats the  
purpose of a cloud in the first place.

So let's focus on VM, but leave extensibility in place so this spec  
could be used inside the cloud.

On 25 Mar 2009, at 09:09, Ignacio Martin Llorente wrote:

>>
>
> Hi Sam,
>>
>>
>>
>> You're still focusing on VMs - I'd be interested to hear your
>> explanation as to how catering for everyone's needs (as proposed by
>> a number of us) will be any more complex than restricting the spec
>> to your own requirements.
>
> Yes, my position is that if we want the group to succeed we should
> only focus on virtual machines (virtual execution environments,...).
> Not in "virtualized resources", because resource could mean not only
> "machine" but also network, storage... In fact I think that the first
> step (after gathering requirements form use cases) should be to create
> a document clearly defining entities to be managed, their life-cycle
> and the associated processes to manage the life-cycle. I think that
> the management of physical resources or light-weight VMs should be out
> of the scope of the group, because that has different implications in
> the life-cycle and processes, and, as far as I know, there are other
> groups working on this (at least for physical resources).
>
> There are many organizations and projects interested in VMs, not only
> Sun or OpenNebula:
>
> - IaaS providers: Amazon EC2, ElasticHosts, GoGrid, Flexiscale, Sun
> Cloud....
> - Research projects: Reservoir, Eucalyptus, Nimbus, SLA at SOI...
> - Users (service management offerings): CohesiveFT, RightScale...
>
>>
>>
>> Aside from that the "network tag" suggestion I made before would
>> allow for the creation of private networks (two interfaces with the
>> same tag would obviously be wired together) but assigning meaning to
>> those tags (subnet details, etc.) would be left to the fabric. The
>> vast majority of workloads don't care, so long as they can talk to
>> each other and their clients (assuming they have any which is not
>> always the case).
>
>
> Fully agree with you on this,
>
> Regards
>
> Igancio
>
>>
>>
>> Sam
>>
>
> _______________________________________________
> Capi-bof mailing list
> Capi-bof at ogf.org
> http://www.ogf.org/mailman/listinfo/capi-bof

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.