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

Jehan-Guillaume de Rorthais jgdr at dalibo.com
Thu Nov 26 00:13:36 UTC 2015


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Build.PL
Type: application/x-perl
Size: 3443 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20151126/a4176a26/attachment-0012.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OCF_Directories.pm.PL
Type: application/x-perl
Size: 3743 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20151126/a4176a26/attachment-0013.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OCF_Functions.pm
Type: application/x-perl
Size: 12492 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20151126/a4176a26/attachment-0014.pl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OCF_ReturnCodes.pm
Type: application/x-perl
Size: 1859 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20151126/a4176a26/attachment-0015.pl>


More information about the Users mailing list