Daniel P. Berrange wrote:
Both will simply be subclasses of the network table, which will need to have a 'type' column in it. Thus each can validate the fields it needs separately, for example virtual networks would validate the vlan number and network fields are present before allowing creation, update operations, etc.On Thu, Oct 23, 2008 at 04:34:47PM -0400, Mohammed Morsi wrote:Daniel P. Berrange wrote:The network configuration UI discussions have all focused around the idea of configuring NICs on machines. I've been thinking that this is really not the right model. You have some kind of physical topology which is known, and has certain properties like network address and prefix, and vlan. A host has one or more NICs, each of which is connected to a network. So if we can model a network as a global entity in its own right, we can simplify configuration of host interfaces, so simply a matter of association, and optionally defining an address. * Network - addr config eg, none, static vs dhcp - network address eg, 192.168.122.0 - prefix eg, /24 - usage eg, storage, management, guest - vlan number eg, 43 - vlan network eg, name of host network * Interface - name eg eth1 - mac eg 00:11:22:33:44:55 - addr config eg, static vs dhcp vs none With the association being: 1 n n 1 Network <-----> Interface <----> NodeBased on our discussion today the following things are needed for this 1. Add new networks table, subclassed into virtual and physical networks, and associated with ip_addresses tableWhere does this virtual vs physical network distinction come from ?
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.One additional thing that comes to mind as I read over the proposed changes is that this network model fits nicely with DHCP assigned nics / interfaces as the nic is associated with the network which it is to receive that information from, but for static assignments it doesn't fit so nicely. This is because the nic / interface will still need to be associated with an ip address directly and not just a network. If so we'd still need the associations between those tables, and might require some validation to make sure the assigned ip is valid for the selected network (or would no network be selected in that case?).Static ip info is no trouble at all. You can still associate an IP address with with the interface directly. In fact you could even suggest a suitable static addres by looking at the netmask of the Network, and what static addresses are already known, and pick an unused one. In addition, even if the network is configured for DHCP, you may still wish to give certain hosts static ip addrs, so you need to maintain the IP address against the interface anyway. With both the network, and interface you need to cope with multiple addresses - both IPv4 and v6 1 n n 1 Network <-----> Interface <----> Node ^ 1 ^ 1 | | V n V n NetAddress Address In the NetAddress you store the network address (192.168.122.0) and the network prefix (/24). In the 'Address' you merely store the address '192.168.122.0'. You can't directly enforce validity constraint of network address + prefix matching the NIC address, because SQL just isn't that expressive. Daniel