[occi-wg] Instance runtime API

Alexis Richardson alexis.richardson at gmail.com
Mon Apr 20 09:01:40 CDT 2009 

Meb,

Sounds good!  The occi-wg wiki has a place to describe your use cases,
so feel free to stick some on there :-)

alexis


On Mon, Apr 20, 2009 at 2:08 PM, Marc-Elian Bégin <meb at sixsq.com> wrote:
>
> 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