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