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
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
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 > > >Based 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 table 2. Unassociate nics and bondings with ip addresses, associate with networks 3. Change any backend components that depend on the model changes 4. Add tab to dashboard if user is able to edit default pool for networks, allowing user to view, create, edit, delete networks. Should come with FIXME to change permissions to something more robust, either by subclassing Network table from Pool (breaking necessary bits into any additional tables) or the most rebust way, to refactoring the permission model to accommodate permissions assigned to any object 5. Update nics / bonding interface to associate w/ a network as opposed to an ip address. I can take care of the interface bits (eg 4,5) if Darryl or someone else takes care of the first three. 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?). -Mo
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 relationI 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