Bug 825801

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

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

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)

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

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?

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?

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

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

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