On Thu, Sep 29, 2011 at 12:07 AM, Dejan Muhamedagic <[email protected]> wrote: > Hi all, > > On Wed, Sep 28, 2011 at 01:18:27PM +0200, Andreas Mock wrote: >> Hi Fabio, >> >> just my thoughts from the perspective of a user: >> >> a) If I install from source choosing a non-standard installation environment, >> I want to avoid overwriting existing software on a machine. >> That means I expect that using simply --prefix=/usr/local should put >> everything under /usr/local, also OCF_ROOT. >> >> b) After Dejan gave me a hint concerning OCF_ROOT I found that there >> is a configure variable --with-ocf-root. But the handling of the default >> value seems to be different between the participating packages. >> IMHO should the default be derived from the prefixes given. >> 1) If you use the common prefixes you get a standard conform OCF_ROOT. >> 2) If you use different prefixes (why and whatever for) OCF_ROOT should >> be located where you would expect it relative to PREFIX. (and just working) > > Makes sense to me. > >> My finding as by now: As soon as I explicitly set --with-ocf-root to the same >> non-standard path anything seems to work so far. (more tests following) >> >> Best regards >> Andreas Mock >> >> >> > -----Original Message----- >> > From: [email protected] >> > [mailto:[email protected]] On Behalf Of Fabio M. Di Nitto >> > Sent: Wednesday, September 28, 2011 10:57 AM >> > To: General Linux-HA mailing list >> > Subject: Re: [Linux-HA] Install problems with ha resource >> > >> > Hi, >> > >> > On 09/27/2011 04:10 PM, Dejan Muhamedagic wrote: >> > > Hi Andreas, >> > > >> > > On Sun, Sep 04, 2011 at 11:22:39PM +0200, Andreas Mock wrote: >> > >> Hi all, >> > >> >> > >> I downloaded the current resource agent file with >> > >> git clone --depth=1 https://github.com/ClusterLabs/resource-agents/ >> > >> After >> > >> ./configure --prefix=/usr/local --localstatedir=/var/local >> > >> make >> > >> make install >> > >> >> > >> I get the error >> > >> /usr/local/etc/ha.d/shellfuncs: Zeile 96: >> > >> /usr/lib/ocf/lib//heartbeat/ocf-shellfuncs: file or directory not found >> > >> >> > >> After manually corecting the path to >> > >> /usr/local /usr/lib/ocf/lib//heartbeat/ocf-shellfuncs >> > >> I get the error >> > >> /usr/local//usr/lib/ocf/lib//heartbeat/ocf-shellfuncs: Zeile 56: >> > >> /usr/lib/ocf/lib/heartbeat/ocf-binaries: file or directory not >> > > >> > > /usr/local//usr/lib/ocf looks wrong to me. >> > > >> > > It seems like configure.ac has a problem in two places. Not >> > > sure, though. Fabio, can you please take a look at the attached >> > > patch. Not sure why do we need OCF_RA_DIR_PREFIX and >> > > OCF_LIB_DIR_PREFIX. >> > > >> > >> found >> > >> >> > >> So I'm pretty sure that the directories given to ./configure are >> > >> not honoured correctly. >> > >> >> > >> Can someone with the right knowledge correct these problems? >> > >> Or give the right hints? >> > > >> > > You'll need to install first the cluster-glue development >> > > configured with, I guess, --prefix=/usr/local and probably also >> > > --with-ocf-root=/usr/local/lib/ocf. Or wherever you want the >> > > resource agents to live. Also use >> > > --with-ocf-root=/usr/local/lib/ocf for resource-agents. >> > > >> > > This may help a bit, but I'm not really sure if it's the whole >> > > story. You'll need to investigate perhaps more. >> > >> > so ok, I have been looking into this and there are different solutions. >> > >> > It all boils down on the amount of flexibility we want to allow in >> > handling OCF_ROOT. >> > >> > First of all there is a bug in configure.ac in resource-agents ordering >> > for checking values of OCF_ROOT. >> > >> > The value stored in cluster-glue header files overrides what is >> > specified locally (easy fix). Specifying /usr/local will create that >> > /usr/local/usr/lib/ocf. >> > >> > In case we do not detect OCF_ROOT from cluster-glue, we force it to >> > default to "/usr/lib/ocf" but /usr does not come from %{prefix} but >> > rather hardcoded as mandated by spec (IIRC). > > I don't think it's mandated by the spec, at least it doesn't say > so :)
Actually the spec says '/usr/ocf/resource.d': https://github.com/ClusterLabs/OCF-spec/blob/master/ra/resource-agent-api.txt#L132 I guess some packaging guideline got it pushed into lib and the spec wasn't updated. At any rate, it is not intended to be admin/user/builder configurable. > >> > There is also a bug in shellfunction (or other small bits) that needs to >> > be fixed based on how we will decide to handle OCF_ROOT. > > OK. > >> > Questions: >> > >> > 1) if we detect cluster-glue, does it make sense at all to allow user to >> > override the value? my understanding is no, since those 2 have to go in >> > sync all the time. > > If the user does --with-ocf-root then we should allow them to > override. > >> > 2) if we allow override, are people ok to use --with-ocf-root="" as it >> > is now (assuming we fix the previously mentioned configure.ac bug)? What >> > are user expected results? Given the special nature of OCF_ROOT, I would >> > prefer to keep it separate from prefix handling. >> > Mixing prefix and hardcoded paths does not work always nicely. > > We should: > > OCF_ROOT_DIR="$prefix/lib/ocf" > > But the value from glue-config.h takes precedence. > > Finally, --with-ocf-root overrides both above. > > Is that straightforward enough? > > Fabio, what do you say? > > Cheers, > > Dejan > >> > Once I get an idea of people want, I can provide a fix. >> > >> > Fabio >> > _______________________________________________ >> > Linux-HA mailing list >> > [email protected] >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha >> > See also: http://linux-ha.org/ReportingProblems >> >> _______________________________________________ >> Linux-HA mailing list >> [email protected] >> http://lists.linux-ha.org/mailman/listinfo/linux-ha >> See also: http://linux-ha.org/ReportingProblems > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
