[occi-wg] thought on interoperability vs integration

[Richard Davies]

> I think we should define more clearly, by examples, what it means for
> two implementations to interoperate and how they would use OCCI to do
> so, yet retain the right to extend their user APIs arbitrarily.
> 
> Any thoughts on an example for - say - EH and EC2?

EH and GG is probably the right example, given that Randy is on this list!


What it would mean for me is that the same client code works against both
clouds for core functionality. For example, if we take the Simple JSON
Rendering which I just posted

http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/SimpleJSONRendering

then I'd like to see a HTTP GET against our respective endpoints returning
the same format JSON list of nouns, with the same names for the same core
attributes (id, title, cores, etc.).

I'd also like to see the same core verbs at the same actuator URLs - e.g.
http://api.example.com/<id>/stop would stop a server on both clouds.

This doesn't sound much, but it's a long way ahead of where we are today!


As an example of vendor extensions, EH supports VNC access to servers, and
GG supports load balancers. This likely means that EH would have a couple of
extra attributes on a server (e.g. the VNC password), and GG would have a
couple of extra attributes on a network (load balancer configuration) +
possibly some verbs.

We'd reserve part of the namespace for nouns, verbs and attributes for these
vendor extensions. For example, our VNC attribute on a server might be:

  vx_com.elastichosts_vncpassword

and Randy's load balancer attributes on a network might be within:

  vx_com.gogrid_XXXXX

with any verbs he needs within http://api.example.com/<id>/vx/com.gogrid/XXXX

Randy - would this kind of scheme work for you?


Cheers,

Richard.