[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Ovirt-devel] Explicit global network modelling

On Fri, 24 Oct 2008 19:43:58 +0100
"Daniel P. Berrange" <berrange redhat com> wrote:

> On Fri, Oct 24, 2008 at 12:53:57PM -0400, Mohammed Morsi wrote:
> > 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
> > http://www.ovirt.org/page/Redesigned_Network_Configuration If anything
> > looks off, feel free to point it out.
> 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
>  - 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.

Yes, all good points.  I'd just like to put a plug in here too for you to take
a look at the model I am working on for the node side because afaict it is pretty
much identical to what you are working with here.  You'll also end up using it 
to do the actual node configuration so we need to stay in sync.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]