I have the PBS cluster with multiple OS, like RHEL5,6,7, Suse 11, 12.
I would lie to know, how can users chose just only RHEL 5 or 6 but exclude other ones? or chose RHEL 6 or SUSE 11, but exclude other OSs?
Please follow this link ( instead of colors you use the flavour of the operating system )
Thnk you for your answer, but this one in not exactly what I need.
I have the resource: osv
this resource depend on vNode OS. I have some different version of os in cluster: R60 (rhel 6.0), R65 (rhel 6.5), C60 (centos 6.0), C70 (centos 7.0), S12 (suse 12), S11 (suse 11)
I assign it on node depens on OS instaled
s n node1 resources_available.osv=R60
s n node2 resources_available.osv=R65
s n node3 resources_available.osv=C70
s n node4 resources_available.osv=S12
I need the solution for submitting the job with mention couple resources and cluster find that resource in cluster and push the job there. Example how it looks in LSF:
bsub -R “osv==R60||osv==R65” sleep 60
It means cluster will find the vnodes with osv=R60 or osv=R65 and push it on first free vnode, but will skip all free nodes with C70 and S12.
how can I do that in PBS?
Please follow this link:
If you turn osv into a string_array resource, you can create combined types. You can set osv on the RHEL6 machine to resources_available.osv=R60,R60_R65
You can set it on the RHEL6.5 machine to resources_available.osv=R65,R60_R65.
When someone wants R60 or R65, they request it. If they want either or, they request R60_R65.
@adarsh is correct, we are in the process creating a more generic specification that you can make requests with boolean logic. Until we finish that, this trick with the string array should help
Or condition in qsub
Yes, I can. for example: for 4 os versions mthe string will be:
R6,R6_R7,R5_R6,R7_R6,R6_R7,R5_R6_R7,R5_R7_R6, and etc…
And the string have to much. So I have to put all variants…
That is crazy!!!
Agree , it is bit of an inconvenience . The team and community are working to enable the feature in the future release.
I know (from secret agent in Altair) this request was 2 years ago for implementing this future… so? Any updates from the TEAM and Community?!?
Design documents may be found here:
These are among a short list of tickets that are given attention on a regular basis. Syntax of resource requests and scheduler performance are two main concerns. Once our current release cycle is complete, we will return our attention to this project.
If there are aspects of the current design that do not meet your needs or could be improved, we welcome your input.