[occi-wg] Instance runtime API
Marc-Elian Bégin
meb at sixsq.com
Mon Apr 20 08:08:00 CDT 2009
On Apr 20, 2009, at 2:52 PM, Alexis Richardson wrote:
> Meb,
>
> Thank-you ... and yes we are setting our goals to 'achievable
> quickly'.
>
> It sounds like you might be able to contribute some use cases?
With pleasure. With Ignacio Llorente (and others) we've started
StratusLab (www.stratuslab.org/wiki) to look into some of the issues I
mentioned... so through that work we'd could definitely share usecases
(Ignacio ?). From SixSq and our SlipStream work (that's the name of
our in-cloud deployment app), we'd also be able to propose usecases,
this more from a cloud user point-of-view.
I'll monitor the group's mailing list for the next round... but feel
free to poke me if and when needed.
Cheers,
Meb
>
>
> alexis
>
>
> On Mon, Apr 20, 2009 at 1:47 PM, Marc-Elian Bégin <meb at sixsq.com>
> wrote:
>>
>> 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