Bug 1250063 - Host becomes non-operational when activating it from maintenance mode, if you have a required network that was never used
Host becomes non-operational when activating it from maintenance mode, if you...
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
3.6.0
x86_64 Linux
medium Severity medium (vote)
: ovirt-3.6.2
: 3.6.2.5
Assigned To: Martin Mucha
GenadiC
: Automation, Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-04 08:28 EDT by GenadiC
Modified: 2016-02-18 06:16 EST (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-18 06:16:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑3.6.z+
rule-engine: blocker+
ylavi: planning_ack+
rule-engine: devel_ack+
rule-engine: testing_ack+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 48058 master MERGED core: update network status only if there's at least one host with up status Never
oVirt gerrit 50811 ovirt-engine-3.6 MERGED core: update network status only if there's at least one host with up status 2016-01-05 03:49 EST
oVirt gerrit 51354 ovirt-engine-3.6.2 MERGED core: update network status only if there's at least one host with up status 2016-01-05 04:49 EST

  None (edit)
Description GenadiC 2015-08-04 08:28:40 EDT
Description of problem:
When there is a required network on DC/Cluster that the host is located on, then activating the host that is in maintenace mode will put the host in non-operational state with error message that host doesn't comply with the cluster networks (meaning required network is missing)


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create required network on DC/Cluster
2. Put host in maintenance state
3. Activate host

Actual results:
Host becomes non-operational

Expected results:
Host should stay operational (as required network was not attached to host yet)

Additional info:
In 3.5 the behaviour is as follow:
If you didn't attach network to host then putting host to maintenance and activating it will leave the host in operational state and network should stay non-operational
Comment 5 Martin Mucha 2015-11-03 07:33:56 EST
can you be more specific how did you create network in step one?

• if I create "required *unattached* network" and then put host to maintenance and activate it, host will be (after while) back at "up" status. Which seems OK.

• if I create "required *attached* network" and then put host to maintenance and activate it, host will turn into non-operational status, which seems OK as well. If you have just one host, then Network is marked as operational immediately after confirming its creation, since network was attached to this host. It was not attached to any nic, but that should not be important.
Comment 6 GenadiC 2015-11-03 08:44:42 EST
You need to create required network that is assigned to DC and cluster only (not attached to the host)
Then put the host into maintenance and after that activate host
The host will be non-operational when the network is operational

The behaviour that I expect is that the network will be still non-operational and the Host will be up
Comment 7 Red Hat Bugzilla Rules Engine 2015-12-01 19:05:28 EST
Bug tickets must have version flags set prior to targeting them to a release. Please ask maintainer to set the correct version flags and only then set the target milestone.
Comment 8 Red Hat Bugzilla Rules Engine 2015-12-01 19:05:28 EST
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 9 Red Hat Bugzilla Rules Engine 2015-12-01 19:10:40 EST
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.
Comment 10 Red Hat Bugzilla Rules Engine 2015-12-03 08:20:32 EST
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Comment 11 Dan Kenigsberg 2015-12-09 04:54:11 EST
Martin, you should not move a bug to ON_QA (and frankly, not even to MODIFIED) before it is backported to the proper branch, which https://gerrit.ovirt.org/#/c/48058/ does not seem to be.
Comment 12 Red Hat Bugzilla Rules Engine 2015-12-09 04:54:13 EST
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 13 Sandro Bonazzola 2016-01-14 03:25:44 EST
Sorry for the noise with assignee, something went wrong while setting target release.
Comment 14 Michael Burman 2016-01-21 09:36:55 EST
Verified on - 3.6.2.6-0.1.el6

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