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
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.
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
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.
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.
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.
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.
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.
Sorry for the noise with assignee, something went wrong while setting target release.
Verified on - 3.6.2.6-0.1.el6