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.
Created: 11/Nov/16 6:50 AM
Created: 11/Nov/16 6:54 AM
Any updates after that date?
You just confirm my words about 2 years ago
The latest commercial release of PBS Pro (version 18.2.1) happens today, completing our release cycle. We will be focusing more attention on these tickets in the near future. There have been some internal discussions on the syntax qsub will accept, but we have not yet reached a consensus. We would be happy to consider any suggestions you may have. We’re looking for something intuitive that doesn’t conflict with shell syntax and maintains backward compatibility.
May I know why you start looking in to it after 2 years? What did you do before? Why you did not investigate it at least 1 year ago?
I really worried about you support. I will create the ticket, and you will look into it after 2 years… this is scary.
Thank you for expressing your interest in this feature; I know it can be frustrating to see a desired feature languish, especially in a case like this, where work was started, but then it was set aside due to higher priorities.
This feature was initially started by the Altair team, and got to the prototype stage, but no final design was ever completed. The team tries really hard to correctly prioritize new features based on overall customer demand and impact. As you might imagine, there are always a lot of potential new features, and the reality is that this one just hasn’t bubbled up to the top again (yet). I hope the Altair team will be able to focus on it again soon, but, again, that depends on priorities.
In this case, since the design for the feature is not done, you can help move it forward. It would be helpful if you could describe your use case – not just how you could use the feature or what implementation changes you’d like to see in PBS Pro, but really explain your high-level goal(s). For example, I want to be able to allocate either RHEL or SLES nodes is still a bit low level; better would be if you could also explain why? How will this help your users or your site? Understanding the high level use cases really helps achieve a good design.
If you’re interested in contributing to the coding of the feature, even better – we’d love to have your help – just say the word!
Thanks again for your feedback,