Bug 1141514 - Power Management proxy selection keep selecting the same proxy first even is it constantly fails
Summary: Power Management proxy selection keep selecting the same proxy first even is ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 3.5.0
Assignee: Eli Mesika
QA Contact: sefi litmanovich
URL:
Whiteboard: infra
Depends On: 1139643
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-09-14 09:50 UTC by Eli Mesika
Modified: 2016-02-10 19:23 UTC (History)
11 users (show)

Fixed In Version: org.ovirt.engine-root-3.5.0-13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 17:08:35 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 32890 0 master NEW core: use last successful proxy in wait-for-status Never
oVirt gerrit 32967 0 ovirt-engine-3.5 MERGED core: use last successful proxy in wait-for-status Never
oVirt gerrit 34743 0 master MERGED core: skip failing proxy when waiting for status Never
oVirt gerrit 34780 0 ovirt-engine-3.5 MERGED core: skip failing proxy when waiting for status Never

Description Eli Mesika 2014-09-14 09:50:03 UTC 
Description of problem:
Power Management proxy selection keep selecting the same proxy first even is it constantly fails 

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


How reproducible: always


Steps to Reproduce:
1.Have H1 with PM and H2 in cluster C1
2.Have H3 in cluster C2 in the same DC as H1 & H2
3.Block communication from H2 to H1 Pm card
4.Restart H1 from UI Power Management 

Actual results:
Stop command is trying to use H2 as a proxy and fails and then use H3 as a proxy
From this point the status of H1 is probed in a loop each 10 seconds
In each such status command an attempt to use H2 as a proxy is done first possibly waiting each time for this operation to fail (20 sec default timeout in ipmilan) and just after that using successfully H3 as a proxy 

Expected results:
After H2 fails on stop/start command all attempts to get the status should be with the one that succeeded to serve as a proxy for the stop/start command 

Additional info:
Comment 1 Eyal Edri 2014-09-28 11:29:46 UTC 
this bug was moved to MODIFIED before vt4 build date thus moving to ON_QA.
if you belive this bug isn't in vt4, please report to rhev-integ
Comment 2 sefi litmanovich 2014-10-02 11:43:46 UTC 
Tried to verify with vt4 - rhevm-3.5.0-0.13.beta.el6ev.noarch.

Couldn't verify due another bz:

https://bugzilla.redhat.com/show_bug.cgi?id=1139643

tried to verify according to flow in the description, the first status with H2 failed, later the first stop command by H2 was reported as successful although the connection between H2 and H1's agent was blocked, then start allegedly worked as well and because nothing actually happened with the host it came back up in no time. this is exactly what happens in bz 1139643.
Comment 3 Eli Mesika 2014-10-02 14:31:02 UTC 
Please make sure that you are checking on a version that had fixed 
https://bugzilla.redhat.com/show_bug.cgi?id=1139643

The fact that stop command was reported as successful although the connection to proxy host was blocked shows that you are testing on a VDSM that does not include the 1139643 fix 

Please attach  /usr/share/vdsm/API.py from the host that was selected as a proxy for the STOP operation
Comment 4 sefi litmanovich 2014-10-14 13:52:58 UTC 
Reproduced this bug on rhevm-3.5.0-0.14.beta.el6ev.noarch according to description.
Comment 5 sefi litmanovich 2014-12-03 11:55:26 UTC 
Verified with rhevm-3.5.0-0.20.el6ev.noarch according to description.
Comment 6 Eyal Edri 2015-02-17 17:08:35 UTC 
rhev 3.5.0 was released. closing.
Note You need to log in before you can comment on or make changes to this bug.