[occi-wg] Support Documentation for Today's Meeting

[Richard Davies]

First of all, congratulations to Ignacio, Tino and the UCM team on producing
the first implementation of an OCCI draft - real progress and good work!
I wasn't on the call, but have had a quick look through the links which
Ignacio sent.


One thing which this brings home to me is that there is still significant
work to tie down unresolved areas the OCCI draft so that implementations
will actually be interoperable.

This isn't to criticize the UCM team at all - they have done a good job
working from a draft specification and invented plausible mechanisms to fill
gaps where they have found them.

Nevertheless, I can see quite a few areas in the their draft specs which
clearly (& necessarily) go beyond what the Sep 21 specification draft (the
last which I read) had actually defined.


Taking one example from their site:

<COMPUTE>
  <NAME>MyCompute</NAME>
  <STORAGE>
    <SWAP size="1024" dev="sda2"/>
    <DISK image="ab5c9770-7ade-012c-f1d5-00254bd6f386" dev="sda1"/>
    <FS size="512" format="ext3" dev="sda3"/>
  </STORAGE>
  <NETWORK>
    <NIC network="23" ip="192.168.0.9"/>
  </NETWORK>
</COMPUTE>

This uses XML nesting to specify when storage and network resources and
linked into a compute resource, and has solved several issues such as the
local devices to be used for the storage resources and naming of interfaces.

By contrast, the Sep 21 specification suggests having separate entries for
each resource, and linking them together using mechanisms similar to the
HTTP Link header (with no example given). The spec doesn't yet say anything
about how local devices should be specified.


Another example: UCM do not use any extra management verbs.
http://www.ogf.org/pipermail/occi-wg/2009-September/001235.html
By contrast the Sep 21 spec hints that some will exist, but does not define
any of them.


My feeling is that the main areas where the UCM team have had to innovate
their own solutions are very similar to the list of areas which I had
previously highlighted as needing resolution in my mail:
http://www.ogf.org/pipermail/occi-wg/2009-September/001215.html

However, I'd also be keen for the UCM team themselves to write down a list
of the areas where they believe that they had to go beyond the actual
written OCCI drafts to produce something workable.

And I'd be equally keen for Sam to take a careful look through the UCM links
below, identify every place that the UCM implementation doesn't look like
what he had expected and tighten the draft in these areas to either the UCM
solution or whatever he had intended to write but not yet written.

Cheers,

Richard.


Ignacio Martin Llorente wrote:
> Hi,
> 
> Because we are now (at 16:00 CEST) discussing the OpenNebula OCCI  
> implementation, I am sending some links with relevant info:
> 
> - OpenNebula OCCI API Specification: http://www.opennebula.org/doku.php?id=documentation:rel1.4:occidd
> - Usage Guide: http://www.opennebula.org/doku.php?id=documentation:rel1.4:occiug
> 
> Cheers,
> 
> --
> Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/llorente
> DSA Research Group:  web http://dsa-research.org and blog http://blog.dsa-research.org
> OpenNebula Open Source Toolkit for Cloud Computing: http://www.OpenNebula.org
> RESERVOIR European Project in Cloud Computing: http://www.reservoir-fp7.eu