[Capi-bof] Charter - last call for changes

[Ignacio Martin Llorente]

Hi,

Well, your approach may provide several benefits. I suggest that we  
postpone this discussion, if we finally see that all the entities have  
similar attributes/life-cycle/associated processes, I agree that the  
API could include all of them.

Regards

Ignacio
--
Ignacio M. Llorente, Full Professor (Catedratico): web http://dsa-research.org/llorente 
  and blog http://imllorente.dsa-research.org/
DSA Research Group:  web http://dsa-research.org and blog http://blog.dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org









On 25/03/2009, at 10:36, Sam Johnston wrote:

> On Wed, Mar 25, 2009 at 10:09 AM, Ignacio Martin Llorente <llorente at dacya.ucm.es 
> > 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...
>
> We're mixing issues here. To be clear, I suggest we exclude anything  
> but the most trivial management of fabric resources (including  
> storage and networking), but avoid at all costs unnecessarily  
> placing restrictions on the container itself. To the consumer it  
> doesn't matter whether they are provisioned a physical machine, VM  
> or a "slice" thereof, provided their performance metrics are met -  
> those details will be handled by the provider (and this is where  
> most of the innovation and competition will happen).
>
> All three container categories (physical, virtual, slice) have  
> identical attributes (memory, storage capacity, CPU performance,  
> etc.) as well as the same set of primatives (start, stop, restart).  
> We already need to support multiple VM image formats (even if just  
> for the significant "legacy" install base) so catering for  
> additional formats for physical machines (e.g. 'dd' disk images) and  
> "slices" (e.g. gzipped tar files) comes at no cost and great benefit.
>
> Looking a little further into the future, PaaS is essentially IaaS  
> with smooth rather than "chunky" scalability. A PaaS workload is  
> essentially just a single instance which can scale up (and down,  
> which is just as important) as and when necessary. With fabrics like  
> Cisco's Unified Computing System and massively parallel computers  
> hitting the market it's concievable that before long we'll be able  
> to provision a VM and scale CPU, memory and storage up and down  
> seamlessly and without bound.
>
> 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 have provided three use cases on the provider side already:  
> dedibox.fr (physical), Amazon EC2 (virtual) and Mosso (slices). On  
> the user side it's even more simple - a user has a workload and a  
> set of metrics under which it should be run (price, performance,  
> security, availability, etc.).
>
> 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).
>
> Please be more specific as I am yet to identify any such  
> implications. "Instantiating" or "reserving" a physical machine may  
> take more time than a VM so a call that requires creation of a new  
> physical "container" may want to be asynchronous but most such  
> providers maintain online stock (e.g. Kimsufi who publish 1hr and  
> 72hr availability).
>
> 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...
>
> Yes, but with products already on the market that offer essentially  
> the same thing for an order of magnitude less cost (e.g. Cloud Sites  
> vs EC2) it's pretty obvious where the market will shift even within  
> the (hopefully short) lifetime of this workgroup.
>
>
> 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,
>
> I'm starting to work through the various APIs already and there's  
> some pretty clever things you can do even with this extremely simple  
> methodology.
>
> Sam
>
>