Bug 825801 - PRD33 - [webadmin] RFE: Improve bonding logic
PRD33 - [webadmin] RFE: Improve bonding logic
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
3.1.1
x86_64 Linux
unspecified Severity medium
: ---
: 3.3.0
Assigned To: Lior Vernia
Martin Pavlik
network
: FutureFeature
Depends On:
Blocks: 976154 978223 1019470
  Show dependency treegraph
 
Reported: 2012-05-28 09:54 EDT by vszocs
Modified: 2016-02-10 14:53 EST (History)
16 users (show)

See Also:
Fixed In Version: is1
Doc Type: Release Note
Doc Text:
The drag and drop logic for bonding in the Host Setup Networks window has been improved for ease of use. Now, bonds and interfaces can be joined by dragging one onto another without manual detaching and reattaching. The original network assignments are not overwritten unless specified.
Story Points: ---
Clone Of:
: 976154 (view as bug list)
Environment:
Last Closed: 2014-01-21 12:11:03 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pm-rhel: Triaged+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 13775 None None None Never

  None (edit)
Description vszocs 2012-05-28 09:54:35 EDT
[Hosts main tab | select some host | Network interfaces sub tab | Setup Host Networks button]

We should improve the logic behind bonding physical network interfaces (NICs) within the dialog.

This covers two kinds of operations:
- creating new bond from two NICs (NetworkOperation.BOND_WITH)
- adding NIC to existing bond (NetworkOperation.ADD_TO_BOND)

-------------------------------
Creating new bond from two NICs
-------------------------------

Current behavior:
- bond can be created from two NICs regardless of whether these NICs have networks attached or not
- before the bond is created, both NICs will have their networks detached and moved to "Unassigned Logical Networks" panel

Desired behavior:
- bond can be always created from two NICs, consider following use cases:
  a1) both NICs have no networks attached (both are network-free)
  a2) one NIC has (any kind of) networks attached, other NIC is network-free
  a3) both NICs have VLAN-only networks attached
  a4) both NICs have different kinds of networks attached, e.g. NIC #1 has non-VLAN network and NIC #2 has VLAN networks
- before bond is created, NIC/bond networks will be updated according to previous use cases:
  a1) nothing to do, since both NICs are network-free
  a2) networks from one NIC will be attached to bond (other NIC is network-free)
  a3) VLAN networks from both NICs will be attached to bond
  a4) since networks from both NICs cannot co-exist together, both NICs will have their networks detached and moved to "Unassigned Logical Networks" panel

---------------------------
Adding NIC to existing bond
---------------------------

Current behavior:
- adding another NIC to bond is possible regardless of whether the given NIC has networks attached or not
- any NIC networks will be detached prior to adding NIC to bond (networks attached to bond will stay untouched)

Desired behavior:
- NIC can be always added to bond, consider following use cases:
  b1) NIC has no networks attached
  b2) NIC has networks that can co-exist together with bond networks, e.g. NIC has VLAN networks and bond has also VLAN networks, or NIC has any kind of networks and bond is network-free
  b3) NIC has networks that cannot co-exist together with bond networks, e.g. NIC has VLAN networks and bond has non-VLAN network
- before NIC is added to the bond, NIC/bond networks will be updated according to previous use cases:
  b1) nothing to do, since the NIC is network-free
  b2) NIC networks will be attached to bond, e.g. NIC VLAN networks will be added to bond VLAN networks, or bond has no networks and NIC non-VLAN network will be attached to bond
  b3) since NIC and bond networks cannot co-exist together, NIC will have its networks detached and moved to "Unassigned Logical Networks" panel


Note that when attaching networks to bond, given networks need to be detached before re-attaching them (semantics of NetworkOperation.ATTACH_NETWORK).
Comment 1 Martin Pavlik 2012-05-29 02:50:50 EDT
What if both NICs have assigned Logical Networks (nonVLAN) and user will try bond them?

a) Nothing will happen (user has to detach LN from one of the NICs)
b) rule a4 from comment 1 will apply -> networks from both NICs will be detached
Comment 2 vszocs 2012-05-29 04:15:11 EDT
> What if both NICs have assigned Logical Networks (nonVLAN) and user will try bond them?
>
> a) Nothing will happen (user has to detach LN from one of the NICs)
> b) rule a4 from comment 1 will apply -> networks from both NICs will be detached

In this case, I thought we'd go with option b) -> detach networks from both NICs (since they can't co-exist) and create bond anyway.
Comment 3 vszocs 2012-05-29 04:19:52 EDT
Thanks Martin for pointing this out.

Use case a4 can be rephrased [similar to b3]: both NICs have networks which cannot co-exist together (e.g. non-VLAN vs. VLAN, or each with non-VLAN network)
Comment 4 Simon Grinberg 2012-12-27 11:18:48 EST
(In reply to comment #2)
> > What if both NICs have assigned Logical Networks (nonVLAN) and user will try bond them?
> >
> > a) Nothing will happen (user has to detach LN from one of the NICs)
> > b) rule a4 from comment 1 will apply -> networks from both NICs will be detached
> 
> In this case, I thought we'd go with option b) -> detach networks from both
> NICs (since they can't co-exist) and create bond anyway.

Actually it's A that should happen. 
If you have 20 network on each interface you would not want to restore 40 network on top of the bond. It's better to inform the user on the offending networks and have him remove those first and retry.
Comment 6 Simon Grinberg 2012-12-30 08:34:37 EST
To be clear on high level requirement compared to the detailed design on comment #0. 

Any interface should be able to be dragged on top of any interface other interface to be merged into a bond where Interface in this scope is either Bond or NIC. Both of the interfaces may (but don't have to) contain logical networks. 

To get down to specifics the following table is legal (in all the following the operation includes aggregation of all logical networks on top of the resulting interface)

Dragged      |   On to     |  Result 
-------------------------------------
    NIC      |    NIC      | New bond dialog on which to place the two
-------------------------------------
    NIC      |    Bond     | Add NIC to Bond
-------------------------------------
   Bond      |    NIC      | Add NIC to Bond      
-------------------------------------
  Bond  A    |   Bond B    | New bond dialog with Bond B properties filled in but allows to select Bond A properties*

* This means delete the other Bond and aggregate everything on the selected Bond. Alternative to the dialog, we can decide that this always means merge into B so launch a pop up message saying "This will remove <Bond A> and place all it's logical networks on <bond B>, is this OK?"

Before allowing the above (or after, if more convenient) need to evaluate if the resulting set of logical network can or can't coexist on the same interface. 

If it can - do the Bonding 
If it can't - just block with the proper message "Network X can't reside with ....., please remove that network and retry" similar to what's done today when trying to drag a non-vm non-tagged network to an interface that already has a tagged network (or the other way around). In any case don't try to optimize by merging what you can and moving the reset to the right hand side pan. 

Livnat, are those clear enough?
Comment 9 Lior Vernia 2013-04-08 10:37:49 EDT
Simon,

In case of a network clash (your "if it can't..." clause), I'm not sure we can tell the user which network is the troublesome one; e.g. if there are two NICs, each with a non-VLAN-tagged network on it, either could be detached to make things okay.

So I think a more generic error message might be preferable, such as "The network setup on bond X is invalid, please remove the troublesome network(s) first". The danger here is that the user might not know what is a valid configuration.

The reasonable alternative would be to always "blame" the first non-VLAN network which is encountered during verification (but the "blamed" network would be chosen arbitrarily if there's more than one non-VLAN network).

Your thoughts?
Comment 10 Simon Grinberg 2013-04-11 10:15:59 EDT
(In reply to comment #9)
> Simon,
> 
> In case of a network clash (your "if it can't..." clause), I'm not sure we
> can tell the user which network is the troublesome one; e.g. if there are
> two NICs, each with a non-VLAN-tagged network on it, either could be
> detached to make things okay.
> 
> So I think a more generic error message might be preferable, such as "The
> network setup on bond X is invalid, please remove the troublesome network(s)
> first". The danger here is that the user might not know what is a valid
> configuration.
> 
> The reasonable alternative would be to always "blame" the first non-VLAN
> network which is encountered during verification (but the "blamed" network
> would be chosen arbitrarily if there's more than one non-VLAN network).
> 
> Your thoughts?

Easy, combine the two :), blame the first with generic resolution
For your example "Network X is blocking the operation since there is another non tagged network on this bond"
If this is unmanaged network that prevent the bonding then just catch the first and say it can't be done since network X in not managed by RHEV Manager. 
Etc.
Comment 11 Lior Vernia 2013-04-11 10:44:54 EDT
Will do.

And as per our discussion, for now I'll be implementing the bond-on-bond drag logic a little differently - rather than choose one of the two original bonds, a "create new bond" dialog will open (same as when dragging NIC unto NIC), whose outcome will hold both bonds' networks (as long as they can live together).
Comment 13 errata-xmlrpc 2014-01-21 12:11:03 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2014-0038.html

Note You need to log in before you can comment on or make changes to this bug.