Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 720420 - sys-cluster/resource-agents installs to /usr/lib64/ocf where sys-cluster/pacemaker can't find them
Summary: sys-cluster/resource-agents installs to /usr/lib64/ocf where sys-cluster/pace...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Deadline: 2020-12-07
Assignee: Gentoo Cluster Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-02 10:21 UTC by Dan Goodliffe
Modified: 2020-12-18 08:50 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge.info,6.04 KB, text/plain)
2020-05-04 08:21 UTC, Dan Goodliffe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Goodliffe 2020-05-02 10:21:29 UTC
According to http://www.linux-ha.org/wiki/OCF_Resource_Agents, the scripts should be installed into /usr/lib/ocf/ but Gentoo package is putting them in /usr/lib64/ocf

There's an ocf_root setting in /etc/crm/crm.conf, which was /usr/lib/ocf and I changed it to /usr/lib64/ocf as that seemed the simplest fix, but it made no apparent difference. I also tried adding OCF_ROOT to /etc/sysconfig/pacemaker (referenced in pacemaker.service) but also without luck.

I was using crmsh to add a ocf:heartbeat:IPaddr2 primitive, not sure if that makes any difference.

I did note that /usr/lib/ocf is a compile time constant in a header file and exists as literals in some .so files, and this is the path pacemaker installs its scripts to.

Quite willing to accept I've done something wrong at this stage, but I've run into a dead end at the moment.

Don't have access to the server I was working on right now, but I'm about to try again locally and will be able to provide more details shortly.
Comment 1 Dan Goodliffe 2020-05-04 08:21:48 UTC
Created attachment 635936 [details]
emerge --info
Comment 2 Dan Goodliffe 2020-05-04 08:28:27 UTC
Apologies for the delay in further information... I've got easy access again now, I can provide more as needed.

# crm configure primitive virtual_ip ocf:heartbeat:IPaddr2 params ip="192.168.1.38" cidr_netmask="32" op monitor interval="10s" meta migration-threshold="10"
ERROR: ocf:heartbeat:IPaddr2: got no meta-data, does this RA exist?
ERROR: warning: unpack_config:  Blind faith: not fencing unseen nodes
ERROR: ocf:heartbeat:IPaddr2: got no meta-data, does this RA exist?
ERROR: ocf:heartbeat:IPaddr2: got no meta-data, does this RA exist?
ERROR: ocf:heartbeat:IPaddr2: no such resource agent
Do you still want to commit (y/n)? n

This doesn't log anything that I can find. However, if you answer yes to commit at the end:

May 01 16:09:22 m1 lrmd[337831]:  warning: Cannot execute '/usr/lib/ocf/resource.d/heartbeat/IPaddr2': No such file or directory (2)

Followed by many variations of couldn't get metadata, things not being installed etc.

# cat /etc/crm/crm.conf  | grep -v ^\;
[path]
crm_daemon_user = hacluster
ocf_root = /usr/lib64/ocf

I tried clutching at straws as I'd seen references to the OCF_ROOT environment variable, but no luck:

# OCF_ROOT=/usr/lib64/ocf/ crm configure primitive virtual_ip ocf:heartbeat:IPaddr2 params ip="192.168.1.38" cidr_netmask="32" op monitor interval="10s" meta migration-threshold="10"
ERROR: ocf:heartbeat:IPaddr2: got no meta-data, does this RA exist?
ERROR: warning: unpack_config:  Blind faith: not fencing unseen nodes
ERROR: ocf:heartbeat:IPaddr2: got no meta-data, does this RA exist?
ERROR: ocf:heartbeat:IPaddr2: got no meta-data, does this RA exist?
ERROR: ocf:heartbeat:IPaddr2: no such resource agent
Do you still want to commit (y/n)? n
Comment 3 Dan Goodliffe 2020-05-04 08:33:05 UTC
# emerge -pv crmsh pacemaker corosync resource-agents libqb

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R    ] sys-cluster/libqb-1.9.1:0/20::gentoo  USE="systemd -debug -doc -examples -test" 0 KiB
[ebuild   R    ] sys-cluster/resource-agents-4.0.1::gentoo  USE="-doc -libnet -rgmanager" 0 KiB
[ebuild   R    ] sys-cluster/corosync-2.4.2::gentoo  USE="systemd xml -doc -infiniband -static-libs" 535 KiB
[ebuild   R    ] sys-cluster/pacemaker-1.1.19-r1::gentoo  USE="acl -heartbeat -smtp -snmp" PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_7" 5,244 KiB
[ebuild   R    ] sys-cluster/crmsh-4.1.0::gentoo  PYTHON_TARGETS="python3_6 -python3_7" 980 KiB

Total: 5 packages (5 reinstalls), Size of downloads: 6,758 KiB


Had to manually bump libqb to address a different problem (permissions in /dev/shm, same ebuild, different number) but I don't believe that's related.

# qlist resource-agents | grep IPaddr2
/usr/share/resource-agents/ocft/configs/IPaddr2
/usr/share/resource-agents/ocft/configs/IPaddr2v4
/usr/share/resource-agents/ocft/configs/IPaddr2v6
/usr/lib64/ocf/resource.d/heartbeat/IPaddr2
Comment 4 Christian R 2020-05-14 09:21:46 UTC
can confirm the problem when switching from profile 17.0 to 17.1

in 17.0 we had a symlink /usr/lib -> /usr/lib64 so the resource agents could be found by pacemaker.
in 17.1 the symlink is gone and pacemaker still looking in /usr/lib for the resource agents.
Comment 5 Dan Goodliffe 2020-05-14 09:31:35 UTC
Ah yes... forgot about that change. I was about to try putting some symlinks in place to see if I could get them in as a stop-gap, but paths already exist where I was going to put them:

# qfile /usr/lib{,64}/ocf
sys-cluster/pacemaker: /usr/lib/ocf
sys-cluster/resource-agents: /usr/lib64/ocf
Comment 6 Christian R 2020-05-14 10:09:14 UTC
i added these symlinks:
ln -s /usr/lib64/ocf/resource.d/heartbeat/ /usr/lib/ocf/resource.d/heartbeat
ln -s /usr/lib64/ocf/lib/ /usr/lib/ocf/lib

it also affects drbd, in case someone reads this.
ln -s /usr/lib64/ocf/resource.d/linbit/ /usr/lib/ocf/resource.d/linbit
Comment 7 Dan Goodliffe 2020-05-14 10:22:56 UTC
Ah, thanks... that's done the trick.
Comment 8 Dan Goodliffe 2020-11-12 11:36:18 UTC
I noticed recently that pacemaker and related components have all been masked, which has left me wondering, what is the new/current supported HA solution for Gentoo?
Comment 9 Dan Goodliffe 2020-11-12 15:29:01 UTC
Sorry, ignore that... I see the masking has been lifted, all is well in the world again. Thanks!
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2020-12-18 08:50:00 UTC
FWIU, this package has been revived.  Please CC treecleaners again if the new 'maintainer' doesn't cope.