[occi-wg] vCloud architecture diagrams

[Sam Johnston]

On Sun, Apr 26, 2009 at 8:15 AM, Tim Bray <Tim.Bray at sun.com> wrote:

> On Apr 25, 2009, at 10:42 AM, Edmonds, AndrewX wrote:
>
>  I think one of the big things within presentation is the usage of OVF and
>> its status as a “1st class citizen” in their API
>>
>
> I've been looking at OVF.  There's a lot to like there, but the thought of
> using it for *interop* is awfully scary.  The notion of exposing various
> aspects of machine state or maybe even machine-group state in OVF seems
> plausible, but in the general case, importing OVF that someone else has
> produced and attempting to reproduce what it's describing, in an automated
> way, seems beyond the current state of the art.
>
> I'd be unsurprised and pleased to be told "Everybody knows that, silly".
>  I'd be surprised and delighted if someone put up their hand and said "Oh
> yes, we can do that for arbitrary OVF".  Or possibly I'm just missing
> something obvious.
>

My original designs (I've been working on this problem since well before
OCCI was conceived) had OVF embedded in Atom's content element. The
intention was that it (and its eventual equivalents for storage and
networking resources) be opaque except perhaps for a small but hopefully
growing number of directives. Of course flat legacy formats (VMware's VMX
for example) could be carried as CDATA as well and the number of Internet
media (MIME) types the implementation supported would be a key
differentiator/area of innovation. I've developed XSLT stylesheets to
downconvert to ElasticHosts/GoGrid style flat text format, Q-Layer/Sun style
JSON as well as upconverting to [X]HTML complete with microformats et al -
the Atom base is borrowed from Google's GData.

There's not actually much to the core protocol (except things like ETags for
proxying/caching and conditional retrieval) and everything from state
control to search is handled by extensions. All "resources" (having dropped
the concept of "workloads" and "containers", so compute, storage and
networking objects), are identified by a UUID which you can GET from
<entrypoint>/<uuid> (e.g.
http://example.com/5c60a787-c523-4859-831f-de5356eb3975). They can link to
each other using standard Atom "link" relations and these have attributes
for information like interface/device, IP number, etc.

That is, key information that would normally hide inside OVF (including
information about collections of systems) is specified in OCCI - if the
level of interoperatility gets to a sufficiently high level then we can
migrate over time but we may be pleasantly surprised as we get into the
format discussion and start pulling it all apart.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090426/0001384a/attachment.html