3. What is the nature and description of the request?
"Refreshing capabilities" of a host should not result in the host being brought out of maintenance
4. Why does the customer need this? (List the business requirements here)
"Refreshing capabilities" can be a precursor to further work, having it bring the host out of maintenance mode is counter intuitive.
5. How would the customer like to achieve this? (List the functional requirements here)
"Refreshing capabilities" of a host should not result in the host being brought out of maintenance. That should be done by clicking on "activate".
6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
7. Is there already an existing RFE upstream or in Red Hat Bugzilla?
8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?
9. Is the sales team involved in this request and do they have any additional input?
10. List any affected packages or components.
11. Would the customer be able to assist in testing this functionality if implemented?
Was unable to reproduce
1) Installed a host and wait until it is active
2) Set host to Maintenance
3) Right click menu => Refresh Capabilities
Result : host stays in maintenance after this operation
Interesting, it's consistently doing this for me...
What I did just notice is the following events:
State was set to Up for host h02.rhev.qa.int.phx1.redhat.com.
Failed to refresh the capabilities of host h02.rhev.qa.int.phx1.redhat.com.
Could it be something in the "failure" path that would trigger the host to come back up?
(In reply to Mark Chappell from comment #3)
> Could it be something in the "failure" path that would trigger the host to
> come back up?
Seems so, will check...
Thanks for the additional information
Occurs probably only if the "refresh Capabilities" fails on a host with power management configured
I had tested "failure" path for regular host with no PM , host remained in Maintenance
please attach full engine.log and the vdsm.log of the host that is serving as a proxy for the fencing operation
Verified on 3.6.2-9
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.