Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1177144

Summary: [fencing-policy] engine might select a proxy host that doesn't know how to handle fencing policy
Product: Red Hat Enterprise Virtualization Manager Reporter: Oved Ourfali <oourfali>
Component: ovirt-engineAssignee: Eli Mesika <emesika>
Status: CLOSED CURRENTRELEASE QA Contact: Jiri Belka <jbelka>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: aberezin, ecohen, gklein, iheim, jbelka, lpeer, lsurette, rbalakri, Rhev-m-bugs, yeylon
Target Milestone: ---   
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: org.ovirt.engine-root-3.5.0-28 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-17 17:14:15 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1164308, 1164311    
Attachments:
Description Flags
engine.log none

Description Oved Ourfali 2014-12-24 14:20:06 UTC 
Description of problem:
When the engine selects a proxy for the fencing operation, it might select a proxy from a cluster version lower than 3.5, thus not able to handle the fencing policy.


How reproducible:
Theoretically, 100%

Steps to Reproduce:
1. Have two clusters, one of 3.5 cluster level, and one of 3.4 cluster level
2. In the 3.4 cluster level have a 3.4 host (and not higher than that).
3. The fencing host should be in the 3.5 cluster
4. The 3.5 cluster should have storage option enabled

Actual results:
If these are the only two hosts in your system, then it will choose the 3.4 host.


Expected results:
If these are the only two hosts in your system, no host should be chosen. It should fail with "no proxy host".

If there are other 3.5 hosts in any of the clusters, then one of them should be selected.
Comment 1 Jiri Belka 2015-01-13 13:19:20 UTC 
fail, 3.4 host in 3.4 clstr was used to fence 3.5 host in 3.5 clstr (same DC).

2015-01-13 14:17:09,175 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.FenceVdsVDSCommand] (org.ovirt.thread.pool-7-thread-17) [7c265e53] START, FenceVdsVDSCommand(HostName = dell-r210ii-04.rhev.lab.eng.brq.redhat.com, HostId = f6cf5e37-6460-4d32-b515-ccfe3e4bb423, targetVdsId = f09225b6-b46c-457a-8096-d129983803dd, action = Stop, ip = 10.34.63.242, port = , type = ipmilan, user = root, password = ******, options = '', policy = '{ fencingEnabled=true, skipFencingIfSDActive=false, skipFencingIfConnectivityBroken=false, hostsWithBrokenConnectivityThreshold=50 }'), log id: 2e120a79


3.4 host - dell-r210ii-04.rhev.lab.eng.brq.redhat.com vdsm-4.14.18-6.el6ev.x86_64
3.5 host - dell-r210ii-03.rhev.lab.eng.brq.redhat.com vdsm-4.16.8.1-5.el6ev
Comment 2 Jiri Belka 2015-01-13 13:20:29 UTC 
Created attachment 979618 [details]
engine.log
Comment 3 Jiri Belka 2015-01-13 13:22:12 UTC 
ooops, looks like i'm lagging one version behind :/
Comment 4 Oved Ourfali 2015-01-13 14:07:00 UTC 
In addition, note that the only relevant piece is the skip fencing if SD are active. So, if this isn't checked in the policy, then 3.4 host can fence a 3.5 one.

That's what I meant by:
"The 3.5 cluster should have storage option enabled"

Sorry for not elaborating more in the description.
Comment 5 Jiri Belka 2015-01-15 13:46:06 UTC 
ok, vt13.7

when fencing policy is used, a host which doesn't support it does not fence.
Comment 6 Eyal Edri 2015-02-17 17:14:15 UTC 
rhev 3.5.0 was released. closing.