[occi-wg] Atompub: Can we see an example of top level storage and network rendering ?

[Sam Johnston]

Gary,

On Sun, May 17, 2009 at 3:17 AM, Gary Mazz <garymazzaferro at gmail.com> wrote:

> Hi,
>
> Can we see a concrete example of top level storage and network rendering
> with one layer of decomposition ? I'd like to know what it will look
> like, especially  with links applied.
>

The reference implementation at http://occitest.appspot.com/ currently
generates
valid Atom<http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Foccitest.appspot.com>and
while it has basic links between resources, it lacks things like the
local identifier (e.g. "eth0" or "sda") because there are a number of ways
to skin this particular cat:

   - add them where possible as generic attributes in the main occi
   namespace (only really applies to the local identifier, but it does
   generally make sense to give a local handle to any resource):
   <link ... occi:localname="eth0" network:address="1.2.3.4" />
   - add them as specific attributes in the extension namespaces (e.g.
   network:interface, storage:device)
   <link ... network:interface="eth0" network:address="1.2.3.4" />
   - add them as elements under the link element
   <link ... >
     <network:interface>eth0</network:interface>
     <network:address type="ipv4>1.2.3.4</network:address>
   </link>
   - some combination (
   <link ... occi:localname="eth0">
     <network:address type="ipv4>1.2.3.4</network:address>
   </link>

I got the idea of having them as elements under the link element from
Microsoft's Astoria team blog <http://blogs.msdn.com/astoriateam/>,
specifically the post on Related entries and feeds: links and link
expansion<http://blogs.msdn.com/astoriateam/archive/2008/02/18/related-entries-and-feeds-links-and-link-expansion.aspx>.
The suggestion has been expanded and is approved
of<http://blogs.msdn.com/astoriateam/archive/2008/02/18/related-entries-and-feeds-links-and-link-expansion.aspx#8573352>by
Joe Gregorio/Google too.

This is *very* relevant for performant/scalable serialisation/migration of
infrastructure between providers (e.g. portability)... it means essentially
that we can follow Tim's suggestion of using links to advertise e.g. OVF
versions of resources, but then when required we can also dereference and
safely include the content inline under the link element:

<link href="http://example.com/810a39a0-f8a4-49f7-8844-0399b4499c6f.ovf">
>   <content type="application/ovf+xml">
>     <!-- OVF content here -->
>   </content>
> </link>
>

Obviously one would only dereference links when requested to do so, and even
if they were dereferenced (e.g. by clicking "Save As..." on your cloud) they
wouldn't get in the way of simpler implementations that don't care about
them. It's about as clean & elegant as we're ever going to get if we're
expecting portability.

Incidentally currently storage and networking devices don't link to anything
(though they could - a virtual network pointing back at a physical one or a
logical volume pointing back at a physical RAID). The compute resources are
more interesting because they point to both. If you're having trouble
retrieving the feed in its current form I've attached it for you.

Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090517/27258347/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: occitest.xml
Type: text/xml
Size: 12160 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20090517/27258347/attachment.xml