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

[Alexis Richardson]

Maybe I missed something, but has 'container' been explicitly defined.
 If not, then I think it should be.  Moreover if a distinction between
container and contained matters, this ought to be spelt out, followed
by examples.


2009/3/25 Sam Johnston <samj at samj.net>:
> On Wed, Mar 25, 2009 at 12:50 PM, Ignacio Martin Llorente
> <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.
>
> 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).
>
>>
>> - 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).
>
> Sam
>
>> Regards
>>
>> --
>> 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 12:27, samj at samj.net wrote:
>>
>>>
>>> > If this is not what we want please send an update version of your text
>>> with your ideas.
>>>
>>> Please find attached an updated PDF version of the charter which I hope
>>> will satisfy all parties.
>>>
>>> Kind regards,
>>>
>>> Sam
>>>
>>> <Charter for Open Cloud Computing Interface (OCCI)
>>> .pdf>_______________________________________________
>>> Capi-bof mailing list
>>> Capi-bof at ogf.org
>>> http://www.ogf.org/mailman/listinfo/capi-bof
>>
>
>
> _______________________________________________
> Capi-bof mailing list
> Capi-bof at ogf.org
> http://www.ogf.org/mailman/listinfo/capi-bof
>
>