[occi-wg] Instance runtime API

Mon Apr 20 07:14:49 CDT 2009

Hi Meb,

Thanks again for your feedback.

Yes, I understand the problem (you know that is exactly the aim of  
OpenNebula, to build those "hybrid clouds") an in fact that is  
something that must be done to allow interoperation. I fully agree we  
need it.

Cheers,
--
Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente
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 20/04/2009, at 14:02, Marc-Elian Bégin wrote:

> I understand your desire of resisting 'feature creep'... and I respect
> it!
>
> Here's my 5 cents on the longer term vision and where I come from...
>
> Several of the potential customer I speak to regarding cloud computing
> want what I call an 'inter cloud'!  This means having their own 'inner
> cloud' (running on their own resources within their own
> infrastructure) which can off load to other clouds (e.g. commercial
> clouds) excess requests when their capacity is exceeded and/or when
> certain policy requirements are met (e.g. privacy issues, such as
> 'this machine can run outside of my infrastructure').  All this such
> that their cloud users continue to interact with an elastic service
> (we don't want 'queues' à la grid to creep back into the cloud
> interface semantic).
>
> For this vision to be realised, we need what this group is currently
> doing, but we also need to define our building blocks (i.e. machine
> images) such they are portable between clouds... unless we capture the
> composition of an image at a different level and compose the image on
> the fly as resources are committed!
>
> Again, I don't want this to be a distraction from the currently agreed
> scope, simply wanted to share a bit of longer term vision.
>
> Cheers,
>
> Meb
>
>
> On Apr 20, 2009, at 1:31 PM, Thijs Metsch wrote:
>
>>
>> Hi,
>>
>> I agree with Ignacio. But do not forget, work for OCCI might not be
>> done
>> when we finish this draft @OGF27...Plenty more OGFs to come where we
>> can
>> talk and work on extensions/refinements :-)
>>
>> All the best,
>>
>> -Thijs
>>
>> On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote:
>>> Sam,
>>>
>>> In my opinion, we should concentrate (at least for the first draft)
>>> on the API for the remote management of VMs. I do not see that the  
>>> WG
>>> should now discuss contextualization issues and APIs that could be
>>> used by the VMs to retrieve contextualization info. The  
>>> specification
>>> should manage the VMs as black-boxes.
>>>
>>> Cheers,
>>>
>>> Ignacio
>>>
>>> --
>>> Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente
>>> 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 20/04/2009, at 13:17, Sam Johnston wrote:
>>>
>>>> Ignacio,
>>>>
>>>> FWIW enabling this use case has so far cost us the following blurb
>>>> (under security):
>>>>
>>>> "Resources should be transparently authenticated such that they can
>>>> use OCCI for introspection (e.g. a virtual machine could connect to
>>>> OCCI to discover application configuration parameters, SSH
>>>> authorized_keys, etc.). Authentication must be transparent and  
>>>> could
>>>> be based on MAC address, IP address, interface, etc. "
>>>>
>>>> I don't really want to get down to the nitty gritty of
>>>> charterlawyering but I think it could fall under the scope of
>>>> "lifecycle management" where the resource itself is just another
>>>> actor. Aside from the sysadmin/developer advantages, allowing
>>>> machines to bind themselves to networks/loadbalancers is fairly
>>>> important for failover scenarios and the like too.
>>>>
>>>> We can discuss the details later.
>>>>
>>>> Sam
>>>>
>>>> On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente <llorente at dacya.ucm.es
>>>>> wrote:
>>>> Hi Meb,
>>>>
>>>> While those APIs are highly interesting and required for service
>>>> portability (contextualization of VMs), they are out of the scope  
>>>> of
>>>> this WG.
>>>>
>>>> Regards
>>>> --
>>>> Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente
>>>> 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 20/04/2009, at 12:45, Marc-Elian Bégin wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Please tell me if I'm out-of-scope and/or out-of-sync, as I  
>>>>> haven't
>>>>> read all the email threads and docs the group has produced.
>>>>>
>>>>> Are we considering the API around the interactions taking place
>>>>> between a running instance and the cloud?  I mean by that two
>>>> types of
>>>>> interactions:
>>>>> 1- Hooks required at the end of the boot sequence to bootstrap the
>>>>> connection between a specific image instance and its cloud  
>>>>> context.
>>>>> 2- The interface with the cloud environment to retrieve instance
>>>>> information such as hostname (private and public), instance
>>>>> specific
>>>>> user-data, etc.
>>>>>
>>>>> I realise that this is heavily influenced by my work using EC2.
>>>>> The
>>>>> goal would be to improve images interoperability between clouds,
>>>>> setting aside for the moment the virtualisation technology used
>>>> (which
>>>>> also bring other issues...).
>>>>>
>>>>> Comments?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Meb
>>>>>
>>>>> _______________________________________________
>>>>> occi-wg mailing list
>>>>> occi-wg at ogf.org
>>>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>>
>>>> _______________________________________________
>>>> occi-wg mailing list
>>>> occi-wg at ogf.org
>>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>>>
>>>
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>> -- 
>> 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
>>
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
>
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg