Potential libcloud / OCCI collaboration
Afternoon Alex et al, I write to you as the secretary of the Open Grid Forum (OGF)'s Open Cloud Computing Interface (OCCI) working group. You can find out more about us at http://www.occi-wg.org/ but our aim in a nutshell is to create a truly open standard API for cloud infrastructure services (IaaS), with a final release due in October. I joined the OCCI-WG back in March after running into difficulties making multiple cloud APIs work together due to impedance mismatches between them, and would very much like to see a successful API result such that adapters are eventually not necessary. If libcloud were to support OCCI then not only would it gain access to anyone who implements it, but eventually it could become a primary programmatic inteface for our RESTful API. I see this as a great opportunity for us to collaborate given we are working towards a common goal from different angles. Anyway I've joined this group and will contribute when I can. I encourage you also to join the OCCI working group (copied) and follow our progress. Kind regards, Sam
Sam, On Sat, Jul 25, 2009 at 4:17 AM, Sam Johnston<samj@samj.net> wrote:
If libcloud were to support OCCI then not only would it gain access to anyone who implements it, but eventually it could become a primary programmatic inteface for our RESTful API. I see this as a great opportunity for us to collaborate given we are working towards a common goal from different angles.
I definitely agree. I think the OCCI is great -- do any providers support it currently? Would be awesome to have a sandbox implementation or something? I think it would also be good to model our data types after the ones expected with the OCCI. I had a hard time finding the spec for the OCCI -- could you point me in the right direction? -Alex -- co-founder, cloudkick.com twitter.com/cloudkick 541 231 0624
Alex, On Sun, Jul 26, 2009 at 1:57 AM, Alex Polvi <polvi@cloudkick.com> wrote:
On Sat, Jul 25, 2009 at 4:17 AM, Sam Johnston<samj@samj.net> wrote:
If libcloud were to support OCCI then not only would it gain access to anyone who implements it, but eventually it could become a primary programmatic inteface for our RESTful API. I see this as a great opportunity for us to collaborate given we are working towards a common goal from different angles.
I definitely agree. I think the OCCI is great -- do any providers support it currently? Would be awesome to have a sandbox implementation or something? I think it would also be good to model our data types after the ones expected with the OCCI.
We have a growing list of product and service providers with varying levels of commitment - hoping to have at least two interoperable implementations when the final version is released. We have a test harness running at http://occitest.appspot.com/ (but this was an older approach based on Atom with translations to various other formats - it needs updating). I had a hard time finding the spec for the OCCI -- could you point me
in the right direction?
Most of the information about OCCI is either on the mailing list<http://www.ogf.org/mailman/listinfo/occi-wg>or in GridForge <http://forge.ogf.org/sf/sfmain/do/viewProject/projects.occi-wg>(mostly the wiki and subversion repository). The main topic at the moment is relaxing the control over the URL namespace (nobody tells you that images have to live in /images on the web so why should compute resources have to live in /compute for OCCI?). This introduces great flexibility (think: interaction with your cloud services over WebDAV or subversion in addition to HTTP - that is, drag & drop cloud) but it also makes for some interesting challenges (e.g. enumeration). The point is that the current spec is a moving target right now but will hopefully settle in the coming days and weeks. FWIW I've now had a chance to have a closer look at libcloud (both yours and RedHat's) and while I see client-side "adapters" or "translators" a useful tool for the interim I am concerned that they may distract from the root problem: the absence of a standard API for cloud infrastructure. Here's hoping that both libcloud initiatives (and perhaps also UCI) can work together to create something akin to libvirt, and that we can all work together to solve the problem properly, once and for all. Sam
participants (2)
-
Alex Polvi -
Sam Johnston