[Ovirt-devel] The oVirt networking UI

[Mohammed Morsi]

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.

http://git.et.redhat.com/?p=ovirt-server.git;a=commitdiff;h=7846006ee8d14371d7f57fe3a39ffcb10012b283
http://git.et.redhat.com/?p=ovirt-server.git;a=commitdiff;h=d60ad329594524dca31c31fbec21918b338ee2d5 
(changes to host browser and managed node config are probably of the
most interest here)

One other thing to note is its been about three months since I worked on
this, so my memory is a bit fuzzy. CC'ing Darryl on this as well, as he
did some work previous to my stuff on getting the network device
information from node to server.

Specific comments inline below.

David Lutterkort wrote:
> Hi Mo,
>
> after playing with this UI some more (from the HEAD of next), here's
> what I think needs to be addressed:
>
> Global networks UI:
>
> * Networks should not be autopopulated; 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.



> * 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.

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.

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.


> * 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)


> * 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.



> 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



> * 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.



> * For a NIC on a static network, netmask, broadcast and gateway should be
>   taken from the network, only IP address needs to specified for each NIC
>   
Should be fairly simple to do.



> * 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). 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).



> * Would be nice to indicate that a certain NIC should not be configured by
>   ovirt (for self-managed nodes), i.e. user tells ovirt that NIC x is on
>   network y, but ovirt won't touch the NIC's config
>   
We could potentially just add a flag to the nics table indicating if the
wui should at any point present the edit nic interface / accept its
input. I'm assuming that this flag would be set on the node side, and
passed to the server via ovirt-identify-node. How this last bit would be
accomplished (eg how a node admin would set that flag) I'm not sure, and
is potentially out of scope for now.



> 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.


Overall it seems that most of the stuff should be fairly trivial and I
can spend some time today / tommorow banging these out, though the few
requirements questions will need to be resolved before I can address the
related issues.

     -Mo