Sam, thanks for the brain dump. I got the top level part of it... I'm still little unsure of the model, specifically how property relationships are handled. Lets say each virtual port can have a collection of UNICAST, MULTICAST or BROADCAST type MAC addresses assigned. The mac address collection is represented as a set of links referencing the MAC address entities (port properties). Can the MAC addresses "back reference" the Virtual port instance ? How would this be represented in json ? I guess I'm looking for the mapping to json. Hint Hint Note: I'm not hoping for a discussion of JSON vs xml. We have xml today, so I'm using it for discussion points.. If the decision is to move to json at some point, we need to map the current xml properties to json. I have also included a matrix of network properties for devices and protocols. The matrix is a compilation of several different standards and operating system capabilities. The matrix is only about 15% complete. It's very ugly right now, I'll be completing most of it this week. This is not written in stone and is all open for debate. BTW, the matrix is in excel 2008 xml format. My TODO list for the matrix: We need a way to describe, set and monitor the QOS of a virtual port when the physical port is shared by several VMs or other execution environment. Should we use the same QOS policy model for load balancing across 802.3ad style aggregated links. Additionally, need a model to reconcile TCP Offload engines, iSCSI and HBAs that combine those protocols on multiple ports. cheers -gary Linking Example (the brackets are my comments/narratives): [Network Port Resource MAC example] <entry> <id>urn:uuid:253d83dd-e417-4e1f-88888-8c0a63120475</id> [Network Port Resource Instance Identifier] <title>Network Port Resource #1 for VM #1</title> <summary>Sample Network Port Resource #1</summary> <updated>2009-05-04T09:52:37Z</updated> <link href="/253d83dd-e417-4e1f-9958-8c0a63120471" /> [Network Port MAC Address Instance Identifier (UNICAST)] <link href="/253d83dd-e417-4e1f-9958-8c0a63120472" /> [Network Port MAC Address Instance Identifier (UNICAST)] <link href="/253d83dd-e417-4e1f-9958-8c0a63120473" /> [Network Port MAC Address Instance Identifier (MULTICAST)] <link href="/253d83dd-e417-4e1f-9958-8c0a63120474" /> [Network Port MAC Address Instance Identifier (MULTICAST)] <link href="/253d83dd-e417-4e1f-9958-8c0a63120475" /> [Network Port MAC Address Instance Identifier (BROADCAST)] <link href="/253d83dd-e417-4e1f-9958-8c0a63120476" /> [Network Port MAC Address Instance Identifier (NOT CONFIG'D)] </entry> <entry> <id>urn:uuid:253d83dd-e417-4e1f-9958-8c0a63120471</id> [MAC Address Instance Identifier] <title>Network Port MAC Address</title> <summary>Network Port MAC Address</summary> <topology>Wireless 20TB Future</topology> <addresstype>UNICAST</addresstype> <address>123108098234098</address> <address_nick_name>Private</address_nick_name> <link href="/253d83dd-e417-4e1f-88888-8c0a63120475" /> [Back Link to Network Port Resource Instance Identifier] <updated>2009-05-04T09:52:37Z</updated> </entry> <entry> <id>urn:uuid:253d83dd-e417-4e1f-9958-8c0a63120472</id> [MAC Address Instance Identifier] <title>Network Port MAC Address</title> <summary>Network Port MAC Address</summary> <topology>Wireless 20TB Future</topology> <addresstype>UNICAST</addresstype> <address>123abcdef</address> <address_nick_name>Family</address_nick_name> <link href="/253d83dd-e417-4e1f-88888-8c0a63120475" /> [Back Link to Network Port Resource Instance Identifier] <updated>2009-05-04T09:52:37Z</updated> </entry> <entry> <id>urn:uuid:253d83dd-e417-4e1f-9958-8c0a63120473</id> [MAC Address Instance Identifier] <title>Network Port MAC Address</title> <summary>Network Port MAC Address</summary> <topology>Wireless 20TB Future</topology> <addresstype>MULTICAST</addresstype> <address>ABDF777cdef</address> <address_nick_name>Hulu Channels</address_nick_name> <link href="/253d83dd-e417-4e1f-88888-8c0a63120475" /> [Back Link to Network Port Resource Instance Identifier] <updated>2009-05-04T09:52:37Z</updated> </entry> <entry> <id>urn:uuid:253d83dd-e417-4e1f-9958-8c0a63120474</id> [MAC Address Instance Identifier] <title>Network Port MAC Address</title> <summary>Network Port MAC Address</summary> <topology>Wireless 20TB Future</topology> <addresstype>MULTICAST</addresstype> <address>WOW-12345ALL</address> <address_nick_name>WOW Raids</address_nick_name> <link href="/253d83dd-e417-4e1f-88888-8c0a63120475" /> [Back Link to Network Port Resource Instance Identifier] <updated>2009-05-04T09:52:37Z</updated> </entry> <entry> <id>urn:uuid:253d83dd-e417-4e1f-9958-8c0a63120475</id> [MAC Address Instance Identifier] <title>Network Port MAC Address</title> <summary>Network Port MAC Address</summary> <topology>Wireless 20TB Future</topology> <addresstype>BROADCAST</addresstype> <address>FFFFFFFFFF</address> <address_nick_name>NATO Alerts</address_nick_name> <link href="/253d83dd-e417-4e1f-88888-8c0a63120475" /> [Back Link to Network Port Resource Instance Identifier] <updated>2009-05-04T09:52:37Z</updated> </entry> <entry> <id>urn:uuid:253d83dd-e417-4e1f-9958-8c0a63120476</id> [NOT CONFIG'D MAC Address Instance Identifier] <title>Network Port MAC Address</title> <summary>Network Port MAC Address</summary> <topology>Wireless 20TB Future</topology> <addresstype>NOT CONFIG'D</addresstype> <address></address> <address_nick_name>Any Nick Name Policy</address_nick_name> <link href="/253d83dd-e417-4e1f-88888-8c0a63120475" /> [Back Link to Network Port Resource Instance Identifier] <updated>2009-05-04T09:52:37Z</updated> </entry> address - with a MAC address assigned. We start adding interfaces so we Sam Johnston wrote:
Gary,
On Sun, May 17, 2009 at 3:17 AM, Gary Mazz <garymazzaferro@gmail.com <mailto: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