Altair is considering the addition of a pre-scheduling hook event in the PBS Pro server. It would be invoked just prior to the server informing the scheduler to run a cycle. We’re looking for feedback from the community both in terms of interest in using such a hook and the implementation strategy.
Part of the motivation for adding this hook event is our understanding that some administrators have been utilizing the server_dyn_res script to perform tasks for which it was not intended. A pre-sched hook event would give them the ability to carry out these tasks in a supported manner.
One concern we’ve discussed is performance, and how the server will be affected. We believe that making the hook non-blocking would address this to some extent. For example, if the hook needed to interact with license servers it may take several seconds to complete. While this would impose a delay prior to starting the scheduling cycle, the server could continue servicing incoming requests and job submissions.
We welcome your feedback and any other concerns you may have.
One last request for comments if you have any regarding the addition of a non-blocking pre-sched hook. If not, I’ll assume everyone is on board with the approach described.
Thanks for sending the reminder out Mike. It would be useful to know what use cases this hook will fulfill, that will help us decide whether we can make the hook non-blocking or not, and what kind of access the hook will have.
Thanks for your response @agrawalravi90. It’s my understanding (second hand) that some administrators perform tasks such as license grooming for applications in the server_dyn_res script today. They might also manipulate queues, jobs, and node resources to adjust the values the scheduler will see when it is invoked. Perhaps some of the PBS Pro technical specialists could chime in if they are aware of other tasks administrators currently perform in the server_dyn_res script. Any thoughts on this @sgombosi?
Thanks for the explanation Mike. It would definitely help to hear from the field about this. But if you feel like you have enough information to write up a design doc, then please go ahead.
Hi – It would be great to understand the use cases – more than just what people are implementing using the server_dyn_res script, but really what they are trying to accomplish. From prior experience, asking “why”, then “why”, then “why” again, to get to the real goal/use cases has led to much better (and wildly different) design solutions than were first envisioned.