A quick top-post. The project moved to its own repository. See:
https://github.com/dalibo/PAF/ Any feedback on the perl modules and related questions bellow would still be quite appreciated :) Regards, Le Thu, 26 Nov 2015 01:13:36 +0100, Jehan-Guillaume de Rorthais <j...@dalibo.com> a écrit : > 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. _______________________________________________ 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