>>> Florian Haas <[email protected]> schrieb am 06.07.2011 um 21:51 in
Nachricht <[email protected]>:
> (Your MUA seems to have injected "=" in the toward the end of most
> lines. May want to have a look at fixing that.)
>
> On 07/06/2011 05:40 PM, Ulrich Windl wrote:
> > Hi!
> >
> > As I've written my first OCF RA, I want to install it to test it in the
> > "real life".
>
> Wonderful. I might add it would be extraordinarily useful if you posted
> it somewhere so people can actually look at the code.
It's version "0.1". Once I have it tested in a cluster and I think it works
well enough, I'll provide the code. But I have unanswered questions on how to
install the RA.
Is it true that "ocf" is detected automatically, the provider is the
first-level subdirectory? Then a question: Is it allowed to have a subdirectory
per RA, like .../provider/agent/agent* ? I implemented my metadata as a
separate XML file, and now I wonder if the framework will get confused if the
provider directory contains a non-executable agent.xml file.
>
> I wonder: How does crm locate the existing RAs ("crm ra =
> > classes", "crm ra info ocf:IPaddr2")? I found that most RAs are installed =
> > in /usr/lib/ocf/resource.d/heartbeat, very few in
> /usr/lib/ocf/resource.d/p=
> > acemaker/. So where should by RA go?
>
> Into /usr/lib/ocf/resource.d/<provider>, where <provider> is essentially
> a directory name of your choosing. The RA may be a custom one that you
> never intend to share; in that case /usr/lib/ocf/resource.d/ulrichwindl/
> would be entirely appropriate.
OK, see question above.
>
> Or you submit the OCF RA to an upstream project, then
> /usr/lib/ocf/resource.d/<project>/ is fine. That is what the OCF RA for
> the RabbitMQ server does; it installs into
> /usr/lib/ocf/resource.d/rabbitmq/.
>
> Or you choose to submit the RA to the linux-ha project, then (for
> historical reasons) the preferred location would be
> /usr/lib/ocf/resource.d/heartbeat/. At least for the time being, we will
> have a unified namespace for the Linux-HA and Red Hat agents some
> stretch down the road.
>
> This, btw, is explained in
> http://linux-ha.org/doc/dev-guides/_installing_resource_agents.html.
Yes, for most parts.
>
> > I'm not good in reading Python code, but it seems crm uses "lrmadmin" to
> > build the list. Unfortunately the manual page for lrmadmin is very poor:
>
> I am sure Dejan will be thrilled to accept patches for lrmadmin man
> page. I for my part find it quite sufficient, and the RA dev guide is
> there for reference purposes about where to install resource agents.
Naturally you could patch (i.e. write) the man page once you know how the
program works. Without a man page you'll have to read the sources, I'm afraid.
Having to read the sources of a program to be able to use it is not the best
choice IMHO.
>
> > Also for updates, should the RA be versioned?
>
> Yes, that is why the metadata has a "version" field. Thanks for
> highlighting the fact that this is not immediately evident from the dev
> guide; I'll fix that.
I meant this: maybe you have an RA found in a subdirectory named "RA-0.1"
(taking about filenames), and maybe you have a symlink "RA -> RA-0.1". Now you
could configure "RA" and rely on the fact that all future versions will be
compatible, or you could configure "RA-0.1" to use a specific version. Now when
there is an update to "RA-0.2", that update might also change the symlink to
"RA -> RA-0.2".
Is something like that supported, or even recommended?
Regards,
Ulrich
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
