search

ClusterLabs / resource-agents

Combined repository of OCF agents from the RHCS and Linux-HA projects
GNU General Public License v2.0
493 stars 583 forks source link

HA_BIN backward compatibility #330

Open kskmori opened 11 years ago

kskmori commented 11 years ago

This breaks the backward compatibility with the heartbeat stack.

285 Low: build: Move binaries in /usr/lib/heartbeat to /usr/libexec/heartbeat to avoid multi-lib inconsistencies

The heatbeat init script expects the heartbeat binary resides in $HA_BIN/heartbeat (/usr/lib64/heartbeat/heatbeat) but it now tries to look /usr/libexec/heartbeat/heartbeat and fails.

dmuhamedagic commented 11 years ago

I'd vote to revert the commit 1e79b78 as this update would break the existing installations. @davidvossel: David, what do you say? Is that commit really that important?

davidvossel commented 11 years ago

The correct place for this sort of thing is libexec. It's weird that we are putting binary executables (things that are not libraries) in the /usr/lib and /usr/lib64 directories.

My primary reasoning for this change is to avoid the multilib conflicts that arise when building rpms of different architectures. Could we not add something to the build system to optionally place symlinks in the /usr/lib63/heartbeat directory to get around the backwards compatibility issue?

dmuhamedagic commented 11 years ago

On Thu, Oct 10, 2013 at 07:05:49AM -0700, David Vossel wrote:

The correct place for this sort of thing is libexec. It's weird that we are putting binary executables (things that are not libraries) in the /usr/lib and /usr/lib64 directories.

Perhaps Lars would know why that was the case with heartbeat. @lge, do you?

My primary reasoning for this change is to avoid the multilib conflicts that arise when building rpms of different architectures. Could we not add something to the build system to optionally place symlinks in the /usr/lib63/heartbeat directory to get around the backwards compatibility issue?

I think that you're missing the point here. There are heartbeat installations which expect the HA_BIN environment variable which is set in resource-agents to point to the directory where heartbeat's executables are placed. Hence, we cannot change HA_BIN at all. If we do so, the existing installations won't be able to start anymore.

Now whether that's technically right or wrong and how all packages coming from Heartbeat depend on each other is another issue.

davidvossel commented 11 years ago

I didn't realize heartbeat was coupled to resource-agents in that way. I can see why this breaks compatibility (regardless of how bad of an idea I think coupling these two projects like that is)

I guess we'll need a build system option for setting a custom HA_BIN directory then.

l-mb commented 11 years ago

I don't think it was an intentional coupling. resource-agents were split out from heartbeat and the two continued to use the same variable. Could, of course, be fixed by having newer versions of resource-agents conflict with older heartbeat versions.

dmuhamedagic commented 11 years ago

On Mon, Oct 14, 2013 at 01:06:13PM -0700, Lars Marowsky-Brée wrote:

I don't think it was an intentional coupling. resource-agents were split out from heartbeat and the two continued to use the same variable.

Right. And this is probably not the only variable. It may take some serious analysis and quite a bit of time to find out what is used where. Furthermore, privately developed RA source various ocf-* scripts, so we should all think twice before moving things around.

I'm not sure how to solve the multilib problem, I'm not even sure what is it exactly. And why is it that we never had it before? Also, on a recent pacemaker I still see /usr/lib64/pacemaker/crmd.

davidvossel commented 11 years ago

All pacemaker components live in /usr/libexec/pacemaker/, all pacemaker tools live in /usr/sbin/. It has been this way since i started on the project (~2 years) , but it wouldn't surprise me if things were different in the past. Perhaps people are distributing it differently then we are in fedora/rhel for some distros.

The multilib problem boils down to this. We don't want scripts hardcoding references to different library or header locations based on what architecture it is built under. ocf-directories HA_BIN references /usr/lib/heartbeat for 32bit, and /usr/lib64/heartbeat for 64bit.

dmuhamedagic commented 10 years ago

We don't want scripts hardcoding references to different library or header locations based on what architecture it is built under. Who's "We"? Why was this enforced on upstream when it seems to solve a specific distribution's packaging issue? Can we please have a better argument when breaking existing installations.