[Ovirt-devel] The oVirt networking UI

[David Lutterkort]

On Thu, 2009-02-05 at 16:32 -0500, Mohammed Morsi wrote:
> As a head note I feel that some of the issues may stem from these two
> patches, as some of the requirements for network related configuration
> we unclear and I did the best I could with what I had.

Yeah, it seems that some of this has to do with unclear
requirements/intended usage.

> David Lutterkort wrote:
> > Global networks UI:
> >
> > * Networks should not be autopopulated;

This is a pretty serious problem, since over time you get lots of
nonsensical networks; all of them with names that are UUID's of nodes -
Darryl, any idea what causes that ? host-browser shouldn't be stuffing
anything into the networks table, should it ? Or does it ?

> >   leave new NIC's unassigned
> >   (nics.physical_network_id = NULL, but edit NIC screen for nodes barfs if
> >   you have a NULL physical_network_id, though the DB schema allows it)
> >   
> This is failing due to the validation in the nics model:
> 
>    validates_presence_of :physical_network_id,
>     :message => 'A network must be specified.'
> 
> I believe we can probably remove this as you mentioned, though we'll
> have to make sure to take care of the cases in which its assumed to be
> there in the codebase.

Absolutely; I would think that without user intervention, the first NIC
will be used on the 'default' network, i.e. whatever network is used for
PXE booting. All other NIC's are unused.

It would be cleanest to express that by creating a 'default' network
when the DB is first installed, and assign the first NIC to it, and
leave all other NIC's with a physical_network_id of NULL. The default
network should be DHCP, with all three usages.

> > * There's no point in assigning an IP address to a network; that
> >   screen should be called something like 'Routing info' or 'IP setup'.
> >   Actually, there's no point in having a separate 'Edit IP address' form
> >   from the 'Edit' form - when user selects 'Static IP' as the boot type for
> >   a network, add fields for netmask, broadcast and gateway to the 'Edit'
> >   form.
> >   
> The naming can be changed easily, but I thought the point on the network
> object was to encapsulate alot of network information so that a user
> doesn't have to enter this info for each nic.

Yes, for static setup all NIC's on that network will have the same
netmask and broadcast address (and should really have the same gateway),
but different IP addresses.

If you want the user to be as lazy as possible, you could have them just
enter the gateway and prefix length, something like '192.168.50.1/24' -
you can calculate netmask and broadcast address from that (though it's
fine to ask for gateway, netmask, and broadcast address for now, I
wouldn't spend any time on simplifying that bit).

> Essentially this boils down to the two cases, 'static ip' and 'dhcp'.
> With networks of the 'static ip' type, the user would only want to enter
> the routing info on the 'edit network' form and then only enter the
> static ip address on the 'edit nic' form when that nic is associated
> with that network. I suppose the issue here wouldn't be to not show
> either form, but rather to hide the appropriate fields depending which
> one you were looking at.

Yes, exactly - one form, where additional fields show up when you select
the 'Static IP' type.

> For the dhcp case, the user would enter all the info on the 'edit
> network' form, eg ip address and netmask and routing info, and wouldn't
> enter any information on the 'edit nic' form. Both these bits are
> already taken care of, as if a user associates a nic with a 'dhcp'
> network, the ip address form isn't displayed on the 'edit nic' form.

Exactly.

> > * Edit network: can select all three usages, but saving with that does
> >   nothing. It should be legit to assign multiple usages to a network
> >   
> I'm not seeing this bug locally (and I'm running the latest code). I can
> select 0, 1, 2, or 3 usages and when I save, I verify that they are
> associated with the network (and are also selected if you open up the
> form again)

Running against the latest from next, I can't save with more than one
network selected (in firefox-3.0.5-1.fc10.x86_64) - when I click on
'Edit Network' the form just stays there, and only goes away when I
click 'cancel'

> > * When displaying an individual network, also display the Usage
> >
> >   
> Where should the usage(s) be displayed, in the details pane, in the
> networks table, both? Either way this is simple enough to do.

And either would be fine.

> > Edit network for individual node:
> >
> > * NIC's dropdown needs to indicate the name of the interface
> >   
> As we discussed on IRC, if this is coming in from the node (and looking
> at node/ovirt-identify-node/protocol.c it seems that it is), it should
> be fairly trivial to change host-browser to save it to the db (though
> the db field will need to be added). Then all we'd need is a one line
> change to the form in question in order to display the name

Yep. That needs to be done.

> > * NIC's dropdown should remove entries we know aren't external interfaces
> >   like lo and vnetN
> >   
> I'm not sure that we'd want this change to occur at the wui interface
> level (or am I wrong). I'd think it would occur at the
> ovirt-identify-node side to filter out which interfaces on the node are
> not public facing and only transmit those to the server.

Yes, you are right - identify-node should do that filtering, since it's
in a much better position to understand what all those NIC's are.

> > * There's no way to see the list of NIC's for a host and the networks they
> >   are assigned to.
> >   
> This is an interface design issue, and while it can be done quite
> easily, I'm not sure where this would go as it could be potentially big
> (in your test scenario you had alot of nics, even without the
> duplicates, which might clutter the wui a bit). 

We alredy list the NIC's for a host in the details pane - how about
adding interface name and network name (if a network is assigned) to
that list ?

> Also the user can see
> the list by going to the edit network form (albeit I agree we might want
> a read only interface for this information).

No they can't; when you go to the edit network form, you need to select
individual NIC's and divine that the autopulation of the network
dropdown is the current assignment - not really workable.

> > Edit virtual machine:
> >
> > * The UUID next to the VNIC's MAC should be removed (is that the VM's UUID
> >   ? if so, it should go underneath the VM's name); instead, there should
> >   be a dropdown to select the network on which to put the VNIC
> > * When putting a VNIC on a network with static routing, user needs to enter
> >   IP for that VNIC
> >   
> I'm not sure how the information on the edit vm form relates to this
> network system, as this has been there for a while, before the new
> network components were even started. I'm a little reluctant to make
> changes to it until we understand what its being used for (if anything)
> but once again, implementing your suggestions should be easy enough if
> my reluctance is unfounded.

The placement of the UUID field is independent of that - since it's the
VM's UUID, it should go right underneath the name.

For hooking VM's up to a network, the idea is that you indicate on which
network you want the VNIC; that in turn is used to set the 'source'
element for the interface of the VM. So, if a node has its interface
'breth0' on network 'foo', and the user selects network 'foo' for a VM
that gets started on that host, the domain XML for that VM needs to
contain something like

        <interface type='bridge'>
            <mac address='00:16:3e:3f:30:a3'/>
            <source bridge='breth0'/>
        </interface>

>From a UI point of view, you need an additional dropdown on the 'Edit
VM' form next to the VNIC's MAC address that lists all the networks on
which hosts in that hardware pool have interfaces.

It also requires that we store the network name with each VM in the db
(additional column for table vms) and that taskomatic uses that in
task_start_vm to determine from the node and the VM's network name which
bridge to connect the interface to.

Without that, I don't think the whole network UI is all that useful.

David