[ClusterLabs] Antw: Perl Modules for resource agents (was: Resource Agent language discussion)

[Ulrich Windl]

Hi!

A few comments (Build.PL):

The part beginning at
---
$ocf_dirs = qx{
  . "$lib_ocf_dirs" 2> /dev/null
  echo "\$INITDIR"
...
---

is somewhat complicated. Why not do something like
---
$ocf_dirs = qx{
  . "$lib_ocf_dirs" 2> /dev/null
  echo "INITDIR=\$INITDIR"
...
---
and then parse the output to get both, the variable name and the value?

(OCF_ReturnCodes.pm)
Why not replace

our $OCF_SUCCESS           = 0;

with

use constant OCF_SUCCESS           => 0;

?

What's the use of "/g" in "$ARG[0] =~ /(\d+)/g" (OCF_Functions.pm)?

And maybe some working sample RA would be nice to see...

Regards,
Ulrich

>>> Jehan-Guillaume de Rorthais <jgdr at dalibo.com> schrieb am 26.11.2015 um
01:13 in
Nachricht <20151126011336.1ca93535 at firost>:
> Le Thu, 20 Aug 2015 18:21:01 +0200,
> Jehan-Guillaume de Rorthais <jgdr at dalibo.com> a écrit :
> 
>> On Thu, 20 Aug 2015 15:05:24 +1000
>> Andrew Beekhof <andrew at beekhof.net> wrote:
> [...]
> 
>> > > What I was discussing here was:
>> > > 
>> > >  * if not using bash, is there any trap we should avoid that are
already
>> > >    addressed in the ocf-shellfuncs library?
>> > 
>> > No, you just might have to re-implement some things.
>> > Particularly logging.
>> 
>> Ok, that was my conclusion so far. I'll have a look at the logging funcs 
> then.
>> 
>> > >  * is there a chance a perl version of such library would be accepted
>> > > upstream?
>> > 
>> > Depends if you’re volunteering to maintain it too :)
>> 
>> I do. I'll have to do it on my own for my RA anyway. 
> 
> Months are flying! Already 3 of them since my last answer...
> 
> I spent some time to port "ocf-shellfuncs", "ocf-returncodes" and
> "ocf-directories" shell scripts as perl modules called "OCF_Functions.pm",
> "OCF_ReturnCodes.pm" and "OCF_Directories.pm". They are currently
> hiding in our pgsql-resource-agent repository under the "multistate/lib"
> folder. See :
> 
>   https://github.com/dalibo/pgsql-resource-agent/ 
> 
> They are used from the "pgsqlms" resource agent available in the
> "multistate/script" folder. They are supposed to leave in
> "$OCF_ROOT//lib/heartbeat/". The pgsqlms agent has been tested again and 
> again
> in various failure situations under CentOS 6 and CentOS 7. Modules seems to
> behave correctly.
> 
> Before considering pushing them out in a dedicated repository (or
upstream?)
> where maintaining them would be easier, I would like to hear some feedback 
> about
> them.
> 
> First, OCF_Functions does not implement all the shell functions available
in
> ocf-shellfuncs. As a first step, I focused on a simple module supporting
the
> popular functions we actually needed for our own agent. Let me know if I 
> forgot
> a function that MUST be in this first version.
> 
> Second, "OCF_Directories.pm" is actually generated from 
> "OCF_Directories.pm.PL".
> Because I can not rely on the upstream autogen/configure to detect the
> distribution specific destination folders, I wrote a wrapper in
> "multistate/Build.PL" around the "ocf-directories" shell script to export 
> these
> variables in a temp file. Then when "building" the module,
> OCF_Directories.pm.PL read this temp file to produce the final
> distribution-dependent "OCF_Directories.pm". I don't like stuffing too much
> shell in perl scripts, but it's really like the autogen/configure process
at
> the end of the day and this piece of code is only in the build process.
> 
> Cleaner ways would be to:
> 
>   * generate OCF_Directories.pm by the upstream ./configure which already 
> have
>     all the logic
>   * re-implement the logic to find the appropriate destination folders in
>     "Build.PL". I am currently not able to follow this solution as reverse
>     engineering the autogen/configure process seems pretty difficult and 
> time
>     consuming.
> 
> The libs are currently auto-installed with our pgsqlms agent following the 
> quite
> standard way to install perl modules and scripts:
> 
>   perl Build.PL
>   perl Build
>   perl Build install
> 
> Any feedback, advice, patch etc would be appreciated!
> 
> PS: files are in attachment for ease of review.
> 
> Regards,
> -- 
> Jehan-Guillaume de Rorthais
> Dalibo