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? alexis On Mon, Apr 20, 2009 at 1:47 PM, Marc-Elian Bégin <meb@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@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@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@ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@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@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg