[occi-wg] Instance runtime API
Marc-Elian Bégin
meb at sixsq.com
Mon Apr 20 07:47:49 CDT 2009
On Apr 20, 2009, at 2:10 PM, Alexis Richardson wrote:
> Meb,
>
> That's a great longer term vision and one that you will find people
> here share.
:-)
>
>
> Meanwhile, what comments do you have on the OCCI work done so far?
I trust you!! And I'm not sure I could contribute at this stage, both
from an expertise and time view-point. I'm a cloud user, building an
in-cloud deployment framework and image factory... from that respect,
I don't mind writing specific adaptors or connectors for the different
cloud species our application will be interacting with... but I'd like
to be able to reason in terms of 'mammals' or 'reptiles', instead of
'unicellular organisms' and 'energy life-forms'!! What I mean with
this is that if we can create convergence such that cloud species
look, smell and feel more or less the same... life will be a lot
easier... I don't mind learning the language details ('cause I don't
know how to speak 'unicellular' ;-)
If the group can deliver quickly something that reaches general
consensus (I'm not bother with total consensus) it would be
refreshing. We could then move on the the next phase, while letting
the more nitty gritty detail be worked on in parallel... if needed; as
I'm not sure we actually need a spec for this type of work, at least
not at this time... but this is only my personal opinion.
Cheers,
Meb
>
>
> alexis
>
>
>
> On Mon, Apr 20, 2009 at 1:02 PM, Marc-Elian Bégin <meb at sixsq.com>
> 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
>>
More information about the occi-wg
mailing list