>>> Florian Haas <florian.h...@linbit.com> schrieb am 07.07.2011 um 10:09 in
Nachricht <4e1569bd.2010...@linbit.com>:
[...]
> > 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.
Hi!
(This time a plain "reply" seems to address the list)
I decided to use a separate file, because I'm using Emacs, and loading an XML
file will properly highlight the XML. With the proper mode, you can even do
nice XML editing. You can easily verify the XML, and the implmentation of
"meta-data" in my case is very simple:
meta-data)
cat "${0}.xml"
;;
No extra hassle with quoting of magic shell characters, etc. I agree that
you'll have to take care that the RA and the XML are in sync, bu tyou also have
to take care if that's one file.
> 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.
OK, that my lack of practical experience and the lack of documentation in this
area.
[...]
>
> >>> 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.
OK, I'll try, see, and report ;-)
Regards,
Ulrich
_______________________________________________
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
