Bug 1177144 - [fencing-policy] engine might select a proxy host that doesn't know how to handle fencing policy
Summary: [fencing-policy] engine might select a proxy host that doesn't know how to ha...
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
unspecified
urgent
Target Milestone: ---
: 3.5.0
Assignee: Eli Mesika
QA Contact: Jiri Belka
URL:
Whiteboard: infra
Depends On:
Blocks: rhev35rcblocker rhev35gablocker
TreeView+ depends on / blocked
 
Reported: 2014-12-24 14:20 UTC by Oved Ourfali
Modified: 2016-02-10 19:45 UTC (History)
10 users (show)

Fixed In Version: org.ovirt.engine-root-3.5.0-28
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 17:14:15 UTC
oVirt Team: Infra


Attachments (Terms of Use)
engine.log (318.84 KB, application/x-gzip)
2015-01-13 13:20 UTC, Jiri Belka
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 36389 ovirt-engine-3.5 MERGED core: fencing proxy should be checked for cluster level Never
oVirt gerrit 36390 master MERGED core: fencing proxy should be checked for cluster level Never

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.


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