Created attachment 1268354 [details] logs Description of problem: Host should be Non-operational when ovirtmgmt isn't attach to host Version-Release number of selected component (if applicable): ovirt-engine-4.2.0-0.0.master.20170402072517.gitb0c121a.el7.centos.noarch vdsm-4.20.0-577.git62a070c.el7.centos.x86_64 How reproducible: 100 Steps to Reproduce: 1. management_as_role/mgmt_net_role_test case 8 (install_host_with_new_management fixture) Actual results: Host is in up state . Expected results: Host should be Non-operational
We found the specific issue, When setting network as a network management, the network becomes Non-operational. Steps to Reproduce: 1. Create new DC, 2. Create new cluster . 3. Add new network to cluster 4. send in REST: PUT ovirt-engine/api/clusters/<CLUSTER-ID>/networks/<NETWORK-ID> <network> <usages> <usage>management</usage> </usages> </network>
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
The bug was found and opened on mater. Is it proven to be on 4.1 too?
The issue exists in 4.0 and might be even earlier, but didn't affected major flows. Thus it isn't a regression.
(In reply to Yevgeny Zaspitsky from comment #3) > The bug was found and opened on mater. > Is it proven to be on 4.1 too? Our automation test running from 3.6 without any issue, This failed exist on master.
IIUC: * The initially reported bug was caused by improper cleanup you did on the VDSM side. * The current $subject bug was never tested on previous versions (IMHO exists since ever), thus you cannot claim that as a regression. Am I right?
Even not a regression, the fix seems simple enough, and worth getting into 4.1.
Verified on ovirt-engine-4.1.2-0.1.el7.noarch and ovirt-engine-4.2.0-0.0.master.20170429081602.gitb982df7.el7.centos.noarch