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
Build.PL
Description: Perl program
OCF_Directories.pm.PL
Description: Perl program
OCF_Functions.pm
Description: Perl program
OCF_ReturnCodes.pm
Description: Perl program
_______________________________________________ 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
