we are using PBSPro 12 since 2012 at our univerity cluster and are really happy
We are currently trying to integrate some hooks with connection to an mysql system. But in the Administrator Guide (6.16.1) it says that only a limited number of modules are available in pbs_python
Does this have changed in releases after PBSPro 12 ? Which version of python is currently included?
Do you have any idea how it could work else?
Thank you for your help
Greetings from Düsseldorf, Germany
I am very glad to know that you are happy with PBSPro. Please do try the recent PBSPro version as well and I am very sure you will like the latest version even more.
You could always import modules at different location by doing something like below in the hook itself:
import custom_module as module_name
Many things changed since version 12. Currently PBSPro does not ship python with package but uses python (should be version >=2.6 and <3) installed on the system itself.
I hope this will help you
Hi. Version 13 of PBS Pro still has the restricted set of Python modules that can be used, and is shipped with Python 2.5.1. But after that, in the open source version, there shouldn’t be any restrictions anymore. It should be able to access to any modules that come with the Python used (>2.6, < 3, preferably Python 2.7) to compile PBS against.
Thank you for your information!
Maybe i can split out a part of our cluster to test the installation.
Is there any guide for an upgrade from 12 to 14 (OpenSource) ?
PBS Pro 14 is effectively the same thing as PBS Pro 13, but geared for the open source community. You may find the documentation for PBS Pro 13 (including the installation guide) here: http://www.pbsworks.com/SupportGT.aspx?d=PBS-Professional,-Documentation
Because the open source release does not contain packages such as PostgreSQL, it requires them externally. Depending on the OS you are running, there may be differences in versions of these components. Obviously, we can’t test every combination so please proceed with caution. It is possible that upgrading an existing installation could corrupt the PBS Pro database, so I encourage you to backup anything you might need if things don’t go as expected.
I would recommend that you generate RPMs so you can easily install the PBS Pro components on multiple systems. There are instructions for generating the RPMs here: https://pbspro.atlassian.net/wiki/display/PBSPro/Building+PBS+Pro+Using+rpmbuild
Once the RPMs are installed, you may need to update /etc/pbs.conf and PBS_HOME/mom_priv/config prior to starting the PBS Pro services. If the services fail to start you should see instructions on what needs to be updated.
If anything goes wrong, please let us know so we can get it fixed.
Thank you for your explanation.
I will have a look into the manuals and check if i can realize my ideas with it.
We want a pre execution hook which can fail a node just before starting the job on a node. But the runjob hook does not run on every vnode and the execjob_begin hook does not have the right to change vnode state. Any idea?
If you use any of the mom hooks, in particular execjob_begin hook, you’re only allowed to change the node state of those nodes managed by the local mom, where the hook is executing. The execjob_begin hook runs on the other sister moms as well, so perhaps you can design the execjob_begin hook to detect which host it is executing, and change the node state of the nodes the mom is managing. When walking through the list of nodes assigned to the job via pbs.event().vnode_list, you’ll find the vnodes that are managed locally have attributes and resources_available.* set.
I tried to use execjob_begin together with
pbs.vnode.state = pbs.ND_OFFLINE and event.reject() but it does not work in PBS 12
The Programmers Guide of PBS 13 says that this should be possible (18.104.22.168) with execjob_begin in combination with fail_action for the hook. Does anyone has tested it ?
Sorry for the confusion in the documentation. The pbs.vnode in this case refers to an actual pbs vnode object obtained from:
vn = pbs.server().vnode(“vnode_name”)
vn.state = pbs.ND_OFFLINE
or in a mom hook:
for v in pbs.event().vnode_list.keys():
[indent]pbs.event().vnode_list[v].state = pbs.ND_OFFLINE
In terms of fail_action, one can set the hook’s attribute to “offline_vnodes”:
qmgr -c “set hook <hook_name> fail_action = offline_vnodes”
which will cause the vnodes managed by the mom executing the hook to get offlined when the hook encounters an unhandled exception or alarm timeout.