[occi-wg] Atompub: Can we see an example of top level storage and network rendering ?
Gary Mazz
garymazzaferro at gmail.com
Mon May 18 05:55:58 CDT 2009
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 at gmail.com
> <mailto: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 --------------
A non-text attachment was scrubbed...
Name: occi_net_properies.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 16230 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/occi-wg/attachments/20090518/8e0f7289/attachment.bin
More information about the occi-wg
mailing list