[Capi-bof] Charter for Open Cloud Computing Interface (OCCI) Working Group

[Andre Merzky]

Quoting [Sam Johnston] (Mar 25 2009):
> Date: Wed, 25 Mar 2009 14:06:57 +0100
> From: Sam Johnston <samj at samj.net>
> To: Ignacio Martin Llorente <llorente at dacya.ucm.es>
> Cc: capi-bof at ogf.org
> Subject: Re: [Capi-bof] Charter for Open Cloud Computing Interface (OCCI)
> 	Working Group
> 
>    On Wed, Mar 25, 2009 at 12:50 PM, Ignacio Martin Llorente
>    <[1]llorente at dacya.ucm.es> wrote:
> 
>      - "Workload" could be confusing, there are other WGs working on "job
>      workloads", for example SAGA or DRMAA, we could say "IaaS based
>      services"
> 
>    The term is deliberately vague because I expect it to transform with
>    time - I just didn't talk about this because I didn't want us to get
>    too far ahead of ourselves.
>    To illustrate, say our API were to allow for the deployment and
>    instantiation of an OVF virtual machine today, there would be nothing
>    to stop us from (later on) deciding to allow people to upload arbitrary
>    workloads like debian packages, python eggs, ruby gems, java WAR/EARs,
>    etc. This gives us an easy path to cover PaaS/SaaS later on.

mumble mumble ocean boiling mumble mumble .... ;-)


>    Basically the way I see the API looking initially is that you can
>    upload your virtual machines and depending on the mime-type (e.g. OVF
>    vs AMI vs VMware vs Xen vs Hyper-V) it will be shipped off by the
>    govern[at]or to an appropriate hypervisor. The number of formats
>    supported will become a key differentiator for vendors and providers.
>    When and if we want to also cover PaaS we just add a few primatives
>    (assuming that's even necessary - applications are started, stopped and
>    restarted and have memory, storage, etc. allocations like like VMs).

Applications have other dependencies, other runtime
requirements, other error conditions, etc etc.  
If, when designing the OCCI API, you keep reminding yourself
that the API should also work for applications, eventually,
then you will overdesign, IMHO.  The result may well be a 
huge and generic API which will also work for VMs, kind of.

I'd rather suggest to compartmentalize: from the beginning,
try to keep track of the characteristics both VMs and apps
have in common (you mention memory, CPU, storage, etc), and
try to design those elements of the OCCI API to be reusable
for other (PaaS/SaaS) APIs later on.


>      - I understand that the API will manage (create, cancel, shutdown,
>      pool...) the life-cycle of the "entities" offered by IaaS clouds,
>      where entity could mean Virtual Machine, and potentially slide and
>      physical resource. Why have you added the management of the
>      container?
> 
>    The object model will become clearer as we assess existing APIs, but
>    there will likely need to be some management of images (uploading,
>    security, etc.) independently of the containers (which may be reserved,
>    for example, as in the case of Amazon EC2, or tied to storage devices
>    and/or networks, depending on which object carries this information).

Again I would suggest to (mentally) compartmenalize.  There
is nothing wrong with having one API which manages a
VM/workload lifecycle, one API which manages VM Image
configuration and locality, etc.  Also, it makes it easier
for consumers of the standard to partially implement the
standard.

My $0.02, 

  Andre.


-- 
Nothing is ever easy.