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 <j...@dalibo.com> schrieb am 26.11.2015 um 01:13 in Nachricht <20151126011336.1ca93535@firost>: > Le Thu, 20 Aug 2015 18:21:01 +0200, > Jehan-Guillaume de Rorthais <j...@dalibo.com> a écrit : > >> On Thu, 20 Aug 2015 15:05:24 +1000 >> Andrew Beekhof <and...@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 _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org