[Engine-devel] network features review

Tue May 22 17:31:37 UTC 2012

Please forgive the late response and the lengthy remarks, some you may not like :) 

----- Original Message -----
> From: "Livnat Peer" <lpeer at redhat.com>
> To: "Moti Asayag" <masayag at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Tuesday, May 22, 2012 4:02:11 PM
> Subject: Re: [Engine-devel] network  features review
> 
> On 22/05/12 15:39, Moti Asayag wrote:
> > On 05/22/2012 11:45 AM, Livnat Peer wrote:
> >> Hi All,
> >>
> >> This is a summary of comments we(*) gathered while reviewing the
> >> current
> >> network related functionality in oVirt, we'll open the relevant
> >> RFE/Bugs
> >> but wanted to share first to get comments:
> >>
> >>
> >> Default Gateway:
> >> ----------------
> >> current status -
> >>   In the UI/API we expose to the user the possibility to configure
> >>   the
> >>   default gateway for the host. We expose this option only when
> >>   editing
> >>   the management network.
> >>
> >> comments -
> >> Apparently we do not configure the host default gateway but the
> >> network gateway.
> >>
> >> 1. We need to fix the phrasing to gateway (not default gateway)
> >> 2. Why do we block it for networks which are not the management
> >> network
> >> 3. We need to support configuring the host default gateway.
> >>
> >>
> >> Non VM (Bridge-less) Network:
> >> -----------------------------
> >> current status -
> >> During bootstrap we configure the management network on the host.
> >> We did
> >> not implement configuring bridge-less management network during
> >> bootstrap.
> >>
> >> comments -
> >> 1. Supporting bridge-less network is a new feature,the design of
> >> this
> >> feature did not include changing the bootstrap process which make
> >> this
> >> feature non-useful when it comes to management network.

Bootstarp does not support most of the possible network configuration.
It will fail if there is already a non bridged bond/Vlan etc. 

I think that what should be done here is nothing, the bootstrap need not touch the network configuration at all. All the admin has to do is verify that the host has connectivity to the engine

Then 
1. On initial setup on the engine side, before adding any host allow to edit the management network properties. (Vlan/VM network/MTU etc)
2. Allow to add the host
3. Use setup-networks to assign the management network according to the topology selected by the admin. It can be done easily by allowing the user to detach it and then attach. As long as it is within the context of the edit menu before he hits OK this is allowed.

The above should allow for any supported network configuration to be applied without all the issues and limitations around that ATM. It also simplifies the bootstrap - it does not care about network. 

> >>
> >> Today one can edit a network only when it is not attached to
> >> clusters,
> >> at this point you can change the management network to be non-VM
> >> network, the problem is that we configure the management network
> >> on the
> >> host during bootstrap and we do not get a parameter if to create a
> >> bridge or not (we always create a bridge).

See the suggestion above it also solves this scenario.

> >>
> >> What we end up with is - we can't change the management network
> >> once we
> >> added clusters/hosts but if changing it before attaching a cluster
> >> we
> >> ignore it in the bootstrap process.
> >>
> >>
> >> Check connectivity:
> >> --------------------
> >> current status -
> >> The 'check connectivity' functionality is available only when
> >> editing
> >> the management network, it validates that we did not loose
> >> connectivity
> >> to the host, if we did the changes are rolled backed
> >> automatically.
> >>
> >> comments -
> >> 1. Sometimes when changing configuration of another network we can
> >> 'damage' the connectivity to the host. We want to expose the check
> >> connectivity functionality on any network configuration change.

Agree, and this is should be always the default. 

> >>
> >> VLAN tagging of management Network
> >> -----------------------------------
> >>
> >> current status -
> >> The user can set a VLAN tag on the management network.
> >>
> >> comments -
> >> 1. Any configuration of the management network needs support in
> >> the bootstrap process (see explanation above for bridge-less network)
> >> 2. In case of VLAN tagging it is even more complicated, 

Again the solution suggested above solves this too.

>>>> when
> >> adding a> >> host to oVirt we add it's address and it can not be changed after
> >> the host was added to the system. in the bootstrap process we set the
> >> management network on the nic oVirt engine used to ssh through,
> >> unless the VLAN device is already configured and the IP used for the ssh
> >> is already on this VLAN (for which it will work) we can't set the
> >> network to be on another IP address.

If the IP is on the same network - you should be able to do so.
But this is not the problem, usually the need to change an IP is not during host/node installation, so there is no problem here, if the user wants a different IP at installation phase he need to set it before he adds the host/node, thus you only need to worry about IP changes for already added host (see comment below) 

> >>
> > 
> > The host IP can be change, however it requires re-installing the
> > host, that runs the bootstrap script.
> > 
> 
> yes, thanks for the clarification.

As I recall this is true if the cert is created based on IP and not FQDN. The re-install is required to replace the certs.

What should be done is to use FQDN to create the certs and not the IP. This should allow for change of the rhevm network IP as long as it resolves to the same FQDN.

I think this was fixed when installing using boot strap or add a node from the New host button (But can't be sure). When doing from the node, then last time I checked it still uses the IP of the host.

> 
> >> Rollback network configuration:
> >> --------------------------------
> >> current status -
> >>  We have the option to make changes to the host network
> >>  configuration
> >> and not persist the changes (they won't survive machine reboot)
> >>
> >> comments -
> >> 1. We are missing the functionality of rolling back the changes
> >> (without
> >> rebooting the machine), this functionality is the complementary
> >> behavior
> >> of 'save network configuration'.

Also missing indication that a network topology change has been applied but not saved.
This lead into situations where after setting a configuration and it works the user forgets to save. Everything works well until the first reboot of the node/host. This may happen days/weeks/months after the actual configuration has been changed so the user may not understand what has happened (/me old geezer with bad memory has done it more then once :))

> >>
> >>
> >> Predefined bonds:
> >> -----------------
> >> current status -
> >> In the bootstrap process we create bonds0-5 on the hosts and then
> >> we use them when creating a bond on the host
> > 
> > minor correction: There are 5 bonds, named bond0-4.
> > 
> >>
> >> comments -
> >> 1. Creating the bonds in the host during the bootstrap process is
> >> not
> >> needed and we can let the user choose the bond name (limited to
> >> bondX)
> >> and create bonds only upon request.
> >>
> >>
> >> Editing Network properties while Network is attached to cluster/s
> >> ------------------------------------------------------------------
> >> current status -
> >> Changing the network properties is blocked if the network is
> >> attached to
> >> a cluster.
> >>
> >> comments -
> >> 1. We should relax this approach. to start with we can enable
> >> editing
> >> when there are no active hosts in the cluster/s.

+1

> > 
> > Modifying a cluster network with hosts in it seems problematic,
> > since
> > we'd have to propagate the network changes to the hosts. E.g.
> > updating a
> > network to be bridge-less, or tagging a network.
> > 
> > Perhaps we should allow updating a network only if the clusters
> > have no
> > hosts at all.

I like the first option better. 
I understand the complexity of having mixed mode so I won't dare suggesting doing the propagation on live hosts (Though on some properties this should be possible) however you can relax the above a bit and just request maintenance. Then upon activation, if networks properties are different then the current definition update the host (actually you don't have to check, just send new topo)

There is a difference between placing 100 hosts into maintenance and between placing into maintenance, removing them, change definition and then re-adding. I just changed 3 host and it was irritating. I had to:
1. Place them all into maintenance 
2. Move them into temp cluster with no network requirements
3. Change the network 
4. Move the hosts back
5. Activate.

With the suggest above only steps 1 and 5 are required.  

> > 
> 
> yes, I agree.
> 
> >>
> >> doing more than the above requires substantially more work both in
> >> VDSM
> >> and engine.

Not that much considering what the user will have to do (look at the suggested solution) - it will pay back after the first user that forgot to set a network as vm-network after adding few hosts and calls support.

> >>
> > 
> > Another missing behavior is the capability to refresh Host nics by
> > demand. At the moment it is enabled by activating a host, which
> > requires
> > moving the host to maintenance first or when facing network issues.
> > Else, changes on host nics will not reflect to the ovirt-engine.
> > 
> 
> I agree this functionality comes from different areas, not only
> networking, running getVdsCaps on demand.

getVdsCaps is nothing compared to getAllVmsStats and you do the later every 10 seconds right? so why bother with on demand, why not just read it once a minute?

When the update logic was created hot plug HW, virtual devices (NICs), etc was only a musing new comer, now with UCS and it's like it is a reality. There is no reason not to just update periodically.  

> 
> 
> >>
> >>
> >> Thank you, Livnat
> >>
> >>
> >> (*) we == {Dan Kenigsberg, Igor Lvovsky, Mike Kolesnik, Moti
> >> Asayag,
> >> Muli Salem, Alona Kaplan, Livnat Peer}
> >>
> >> (**) We have even longer list for the UI changes needed, for them
> >> we'll
> >> open bugs directly to avoid another long email.
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 