I still feel that it might be intuitive to allow this, it’s just saying that one can set the value to default as well. And it should continue to work the old way right? un-setting it should still set it to default.
I agree with you Ravi that it will add more flexibility for admins to set things up but I am not certain whether they need it. Especially when there is a way to achieve the same thing without adding more complexity to the product.
It would be interesting to know what @scc thinks about it. If letting admins set default partition on queues/node is something customers would like, I’ll happily add it.
1 Like
I don’t see a need for an additional way to mark a node/queue as part of the default partition aside from unsetting it partition attribute.
Hi,
I want to propose another change to the design document. This change is about disabling the scheduler to support multiple partitions.
Currently, there is no strong use case for a PBS multi-sched to support more than one partition at a time. If an admin wants a multi-sched to handle more than one queues then they can easily do that by assigning the same partition name to multiple queues. Adding support for multiple partitions per scheduler adds a lot of unnecessary complexity to the code and does not behave well when jobs/reservations are submitted with node grouping (because in case of node grouping it may happen that nodes in one group are part of two different partitions and then the job/reservation could potentially run across partitions).
I am proposing to simplify the interface and have each scheduler service only one partition. I’d request the reviewers to have a look at the change and let me know what they think.
Thanks,
Arun
1 Like
@arungrover I like the idea of streamlining the multi-sched code. I don’t see any need for the extra complexity.
Bhroam
Agreed, thanks for bringing this up and resolving it.