Bug 1167698 - [SetupNetworks]> Unmanaged network on host NIC should prevent attaching new networks to this NIC, until unmanaged network is removed
Summary: [SetupNetworks]> Unmanaged network on host NIC should prevent attaching new n...
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: ---
Hardware: x86_64
OS: Linux
Target Milestone: ovirt-4.0.0-alpha
: 4.0.0
Assignee: Marcin Mirecki
QA Contact: Michael Burman
: 1247037 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2014-11-25 09:55 UTC by Michael Burman
Modified: 2016-07-05 08:00 UTC (History)
14 users (show)

Fixed In Version: ovirt 4.0.0 alpha1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-07-05 08:00:02 UTC
oVirt Team: Network
rule-engine: ovirt-4.0.0+
rule-engine: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+

Attachments (Terms of Use)
screenshots (419.97 KB, image/png)
2014-11-25 09:56 UTC, Michael Burman
no flags Details
screenshot (421.52 KB, image/png)
2014-11-25 09:56 UTC, Michael Burman
no flags Details

System ID Private Priority Status Summary Last Updated
oVirt gerrit 46074 0 master MERGED engine: host setup networks validator for unmananged networks 2016-02-14 07:39:49 UTC

Description Michael Burman 2014-11-25 09:55:55 UTC
Description of problem:
[SetupNetworks]> Unmanaged network on host NIC should prevent attaching new networks to this NIC, until unmanaged network is removed.
But this behavior isn't persistent at all.
If i have unmanaged network on host NIC, i can attach new vlan networks to this NIC via label when creating new network. 

Version-Release number of selected component (if applicable):
3.4.4-2.2.el6ev(discovered on 3.4.4)

How reproducible:
Inconsistent behavior

Steps to Reproduce:
1. Create new network and attach to NIC on host.
2. Remove this network(via networks tab on 3.4, via DC tab on 3.5)
3. Create new vlan network and assign it to this NIC via label, create another network like this.

Actual results:
Networks attached to this NIC, that have unmanaged network on him, via label 

Expected results:
Unmanaged network on NIC(network doesn't deleted from NIC), should prevent attaching new networks to this NIC, unless unmanaged network was deleted.

- The behavior is not persistent, because sometimes it prevent from attaching new networks to this NIC and sometimes not.

Comment 1 Michael Burman 2014-11-25 09:56:23 UTC
Created attachment 961113 [details]

Comment 2 Michael Burman 2014-11-25 09:56:54 UTC
Created attachment 961115 [details]

Comment 3 Michael Burman 2014-11-25 10:00:27 UTC
In the screen shots attachments you can see that i have a NIC, that has unmanaged network('kaka'). There is a network 'mic5' that attached to this NIC and there is a network 'kaka2' that can't be attached to this NIC, cause of the unmanaged network. So behavior isn't persistent.

Comment 4 Lior Vernia 2014-11-25 11:48:09 UTC
Should probably be blocked on the backend (if we indeed want to block ANY operation on a NIC with unmanaged networks - it might be harmless to allow VLAN networks).

Not sure if any code needs to be fixed in the frontend though. Michael, if you first label the network, and only then label the NIC via the setup networks dialog - is this blocked by the GUI?

Comment 5 Michael Burman 2014-11-25 12:45:48 UTC
Hi lior,

In that case, this is blocked by the GUI.

Comment 6 Marcin Mirecki 2015-08-18 18:14:47 UTC
I am unable to reproduce the issue.
I have tried this on 3.5.4 and master, in both cases it works correctly. The vlan is not added to the nic, with the message: "Failed to apply changes for network(s) vlan9 on host f21."

The steps to reproduce:
1. Add label to nic
2. Add network
3. Attach network to nic
4. Remove network
5. Add vlan network with appropriate label
6. Network is added but fails to attach to the nic.
Is this the correct way?

Comment 7 Marcin Mirecki 2015-08-19 14:51:04 UTC
I think I managed to reproduce this, but I'm unable to reproduce this again.
The way to reproduce this was to add the first network using labels as well.
So point 2 and 3 above would be: 2. Add a network using with a label
and then delete the network.
Unfortunately this is quite inconsistent. Most of the times the network added using a label is removed from a nic when removed in the networks tab.

Comment 8 Michael Burman 2015-08-19 15:01:04 UTC
Hi Marcin,

Your steps from comment 6 ^^ are ok i think. 
From where do you remove network on step 4 ^^ from host or DC? is it got 'unmanaged' after removing?

Comment 9 Marcin Mirecki 2015-08-20 07:48:43 UTC
I remove it from host.
When I add it using setupNetworks (no labels), it always goes to 'unmanaged'. But in this scenario I was never able to add a vlan to it.
When I add the network with a label (so it gets added to the nic automatically), it will be deleted from the nic when the network is removed (in networks tab). I noticed that a few times the network was not deleted from nic when removed, and in this case I was able to add a new vlan.
Unfortunatelly I don't know under what conditions the labeled network was not removed from the nic, and I'm not able to reproduce this.

Comment 10 Michael Burman 2015-08-20 07:53:12 UTC
You should remove the network from DC while it attached to host.

Comment 11 Dan Kenigsberg 2015-10-26 14:39:38 UTC
*** Bug 1247037 has been marked as a duplicate of this bug. ***

Comment 12 Yaniv Lavi 2015-10-29 12:46:41 UTC
Why did you move this to 4.0?

Comment 13 Dan Kenigsberg 2015-10-29 12:58:47 UTC
The code that implements the requested validation was deemed risky by Alona.
Since a similar protection does not exist in the old API, lacking it in the new API should not be considered as regression.

We do have a patch, and intend to have it merged to master as soon as we can. If customers bump into this and complain, we would revisit our decision not to include it in 3.6.z.

Comment 14 Michael Burman 2016-04-06 05:29:50 UTC
Verified on - 4.0.0-0.0.master.20160404161620.git4ffd5a4.el7.centos.noarch

Comment 15 Sandro Bonazzola 2016-07-05 08:00:02 UTC
oVirt 4.0.0 has been released, closing current release.

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