[Ovirt-devel] Explicit global network modelling

[Perry Myers]

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 <----> Node
> 
> 
> So if you have say
> 
>    * Network: 
>       - 'admin lan'
>       - 192.168.122.0/24
>       - dhcp
>       - usage: management
>    * Network
>       - 'guest lan'
>       - dhcp
>       - usage: guest
> 
> 
> Now, you come to configure a new host with two NICs 'eth0' and 'eth1.
> In this particular scenario all the admin would need todo is pick off
> the 'admin lan' network for 'eth0', and 'guest lan' for eth1. Job done.
> No need to specify any addressing, because the network properties already
> tell us it is a DHCP based LAN. Also, since eth1 is associated with a 
> guest traffic only lan, there is no need for IP config on eth1 in the 
> host. All we need do is put eth1 in a bridge. 
> 
> Also note we don't need to ask the admin whether eth1 should be bridged
> or not. We know for a fact that it must be bridged, because it is a guest
> traffic network. Likewise we know that a admin network does not need a
> bridge. If a network was designated for both mgmt and guest usage, then
> we would need a bridge and IP address config.
> 
> Now an alternate example with VLANs...
> 
>    * Network:
>       - 'office lan'
>       -	none addr config
>       - usage: none
> 
>    * Network:
>       - 'admin lan'
>       - 192.168.122.0/24
>       -	dhcp
>       - usage: management
>       - vlan: 43
>       - vlan host: office lan
>  
>    * Network
>       -	'guest	lan'
>       - dhcp
>       -	usage: guest
>       - vlan: 72
>       - vlan host: office lan
> 
> Now, come to configure a host with two devices eth0 and eth1. The admin
> tells us that both eth0 and eth1 are connected to 'office lan'. With this,
> we know that eth0 and eth1 should be bonded since they're on same lan, 
> so we merely need ask what kind of bonding is desired.  Since we see
> that there are two VLAN networks associated with 'office lan', we also
> know that we have to create two VLAN devices on the host, and that one
> of those VLAN devices must be put in a bridge. Again no need to ask the
> admin about VLAN creation on the host
> 
> So this kind of modelling can make our UI for setting up host networking
> much clearer / simpler, avoiding lots of redundant questions. Also, by
> having an explicit   'network <-> interface <-> host' assoication, we
> can trivally determine whether it is possible to migrate between two 
> hosts from a network topology POV - its merely checking one DB relation

I like this approach, just a small comment.  We need to be able to support 
  defining networks that are some combination of Managment, Guest, 
Storage. So usage can't be a single selection, it needs to be 
multi-selection.  And if guest is one of the selected usages, then the 
bridge is created.

The other question that comes up is: how do we define these networks, 
interfaces in the absence of the oVirt server for when the Node is in 
standalone mode?  We should mirror this type of dialog in a text 
configuration utility that can be put directly on the Node for admins to 
use in standalone operations.  The output of the utility would be a 
configuration file that can be fed to the existing scripts for setting up 
network interfaces via augeas.

Perry