Gary, On Sun, May 17, 2009 at 3:17 AM, Gary Mazz <garymazzaferro@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