Introducing a new conf variable for the scheduler name.
Take a look at the proposal:
https://pbspro.atlassian.net/wiki/spaces/PD/pages/1318387715/New+scheduler+service+name+conf+variable
I’m fine with PBS_SCHEDULER_HOST_NAME, but please don’t use something with “SERVICE” in the name. It implies it has something to do with /etc/services.
Thanks for the proposal Lisa. Just trying to understand the motivation for this change: does the communication issue exist when server and scheduler are in different kubernetes pods, or is it when they are in the same pod?
Hi @agrawalravi90, the issue exists when the server and scheduler are within the same kubernetes pod. We are also setting the PBS_LEAF_NAME to the external-to-the-pod IP address, and the server uses the value of that variable to connect to the scheduler.
I like the change of adding a scheduler host name in general, but I also agree with Mike that it can go without “SERVICE” being mentioned in the name.
Thanks for explaining Lisa. I’m just wondering how this will work with multi-sched, where each sched will have its own port number and possibly its own unique hostname as well. Have you thought about this scenario?
This option is to point the server to the default hostname of the scheduler, and not the port. (the port already has an env var) The functionality is already there with the -S option to the server, but this RFE will add it to the conf file so admins can still use the init script.
This shouldn’t affect any other features.
Thanks for your reply @vstumpf.
I wasn’t concerned about this affecting existing functionality, I was just thinking whether this solution will also work in a multi-sched scenario on kubernetes. So, say, if we have multiple schedulers & the server running inside a pod, will all schedulers be able to talk to the server without any issues? I don’t want us to have to change our approach later to support multi-scheds, so just making sure.
It should work. We need this to talk to the first scheduler. Any other schedulers will either use the same hostname and a different port or a different hostname, just like on a normal setup.
Alright, sounds good. Proposal looks fine to me.
After code got reviewed, we realized that perhaps a better method of setting the scheduler host name for the default scheduler would be to use qmgr. Especially since doing so would match what is done when using multiple schedulers.
This discussion is closed.
Please post comments about the new design at the following forum discussion: