Description of problem: Currently if we remove a logical network, the particular network is not automatically removed from the hosts. We have to manually remove it using "Setup Host Networks". If we try to attach a new network in this stage , we will get error as "Invalid operation, an unmanaged network can only be detached". The error can confuse the The error message doesn't tell any hints to end user why the network is unmanaged. The only indication is "?" sign on the particular network which is already removed. However this is not easy to find if you are having a large number of networks attached to the hosts. For the attached customer case, we was having 65 networks attached to a single bond. Version-Release number of selected component (if applicable): ovirt-engine-4.0.6.3-0.1.el7ev.noarch How reproducible: 100% Steps to Reproduce: 1. Remove a logical network from the RHV-M which is already attached to one of the host NIC 2. Create a new network and try to add it to the hosts. We will get error message as "Invalid operation, an unmanaged network can only be detached" 3. Actual results: Confusing error message when trying to add a new network. Expected results: Provide clear error message including the name of the network which has to be removed in order to make the host network "managed". Additional info:
As shown in https://gerrit.ovirt.org/#/c/70010/ (https://bugzilla.redhat.com/show_bug.cgi?id=1167675), the specific unmanaged networks are now reported. There's still a pending issue of tooltips being incorrect, however the error message now specifies the networks.
Hi Leon, not sure why this moved to ON_QA as this can't be tested until BZ 1167675 is fixed and i don't see any patches added to this bug. Yes, although the message now provide the unmanaged 'network-name' that should be detached, it is still has a bug in the correct network name as the message shows the wrong network names(explained in BZ 1167675 comment# 6). 1) This fix should be done for tooltips as well 2) The error message should be improved and explain that network unmanaged can be also removed(press 'x') and not only detached.
(In reply to Michael Burman from comment #4) > Hi Leon, not sure why this moved to ON_QA as this can't be tested until BZ > 1167675 is fixed and i don't see any patches added to this bug. > Yes, although the message now provide the unmanaged 'network-name' that > should be detached, it is still has a bug in the correct network name as > the message shows the wrong network names(explained in BZ 1167675 comment# > 6). > 1) This fix should be done for tooltips as well > 2) The error message should be improved and explain that network unmanaged > can be also removed(press 'x') and not only detached. To be more clear, 'detached' is the wrong word, as it can't be detached really, only removed by pressing 'x' and it's why the error message still not clear enough.
We have improved the error message, and now it states the name of the problematic unmanaged network. Burman, please suggest an error message and tooltip text. We may consider to address these two remaining tasks, but it is not very likely.
Also see my request to - Add 'Unmanaged' network icon to the front NIC panel - BZ 1477049 I believe that handling BZ 1477049 is the best solution. Dan, what do you think? can we do that?
I like the idea. If bz 1477049 is enough, please close this one and fight for other one.
Although the suggested idea in BZ 1477049 is good, providing a error/warning message about an 'unmanaged' network on the host in the event log UI is good to have too. Similar message event we have for the out-of-sync network should do the work. Can we try to address both in 4.4? if not, i will close this one.
(In reply to Michael Burman from comment #10) > Although the suggested idea in BZ 1477049 is good, providing a error/warning > message about an 'unmanaged' network on the host in the event log UI is good > to have too. Similar message event we have for the out-of-sync network > should do the work. > Can we try to address both in 4.4? if not, i will close this one. Bug 1477049 will address what is not yet fixed by bug 1167675. *** This bug has been marked as a duplicate of bug 1167675 ***