On 2011-07-07 08:23, Ulrich Windl wrote: >>>> Florian Haas <florian.h...@linbit.com> schrieb am 06.07.2011 um 21:51 in > Nachricht <4e14bca8.7070...@linbit.com>: >> (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.
Just as a general suggestion, it may be wise to rethink that approach. It's usually a good idea to float your resource agent early and solicit feedback and ideas for improvement. > Is it true that "ocf" is detected automatically, the provider is the > first-level subdirectory? Well, yes. ocf is the resource agent class. > 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. No it will not; all non-executable files in that directory are ignored. You can put your metadata into a separate file and then simply "cat" that file from the RA's meta-data action, and this is the approach that the Red Hat Cluster agents usually take, but within the Linux-HA crowd that approach hasn't been used, and I personally am not very fond of it. Still, it's essentially up to you -- there is no best practice forbidding separate metadata files. I see no benefit at all, however, in having a separate provider directory for each and every resource agent. >> 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. Suggestions for improvement, and/or documentation patches, are most welcome. >>> 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. Note I wasn't suggesting that you read the source. Reading the aforementioned section in the dev guide should be enough. >>> 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". So now you are talking about not having just one subdirectory per RA, but one per RA and version? Again, I see zero merit in that. If you are worried about rolling upgrades and changes to your agent, that problem is essentially moot. Users are generally expected to either move resources temporarily away from a cluster node which is in the process of being upgraded, or (in cluster managers where this is available, such as Pacemaker) place the cluster in maintenance mode when making software updates. Cheers, Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
