<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel P. Berrange wrote:
<blockquote cite="mid:20081024184358.GA28277@redhat.com" type="cite">
<pre wrap="">On Fri, Oct 24, 2008 at 12:53:57PM -0400, Mohammed Morsi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Just to assist in starting all this, I came up with a quick uml class
diagram for the new network changes incorporating the new classes and
relationships, and accommodating for things like static ip addresses
and the network usage relationship. It can be accessed here
<a class="moz-txt-link-freetext" href="http://www.ovirt.org/page/Redesigned_Network_Configuration">http://www.ovirt.org/page/Redesigned_Network_Configuration</a> If anything
looks off, feel free to point it out.
</pre>
</blockquote>
<pre wrap=""><!---->
Some points
- Network <-> Usage is 0/1-to-n since you can have zero or
more usages for each network
- Having separate tables for 'bonding type' and 'boot type' seems
like overkill to me - I would have just have a single byte field
with a CHECK constraint on it.
- NIC <-> IPAddress is 0/1-to-n since you can have zero or more
addresses for each NIC
- Sub-tables for IPv4 vs IPv6 seems like overkill since they're
not going to be any different in the info they store
</pre>
</blockquote>
<blockquote cite="mid:20081024184358.GA28277@redhat.com" type="cite">
<pre wrap=""> - Don't use the word 'virtual' in association with network - stick to
using VLAN instead. 'virtual' already has a defined meaning in libvirt
application terminology.
- A physical NIC should associate to a physical network, to enforce
that a NIC is a physical connection
- Bond shouldn't associate with network at all, since that's duplicating
info already encoded in the NIC -> physical network association
- A physical NIC & bond should also assciate to VLAN-network, n-to-n to
represent the idea that you can enable zero or more VLAN interfaces.
In fact this suggests you should have a base class NIC, and sub-classes
for physical, bond & vlan interfaces.
Regards,
Daniel
</pre>
</blockquote>
<br>
I updated the diagram. As far as the ipv4/ ipv6 distinction, once again
this is a validation issue, not only do the addresses need
to be validated to be in the correct format, but certain fields of the
ip_addresses table only apply to IPv4/IPv6. I'm still a little unclear
about the nic / bonding and physical / vlan network associations, so
the diagram might be off. <br>
<br>
-Mo<br>
</body>
</html>