Merge CapacitySchedulerConfiguration#setCapacitiesByLabels and CSQueueUtils#setAbsoluteCapacitiesByNodeLabels into a single method
CapacitySchedulerConfiguration#normalizeAccessibleNodeLabels - should AbstractCSQueue#accessibleLabels be updated as well ?
No, if we have ANY in accessible node labels, and cluster's node label collection could change, so we need to keep the "ANY" in case any changes of clusterNodeLabels
why union? newCapacities.getExistingNodeLabels is enough ?
No, this method's semantic is, replace all (absolute)(maximum)capacities, so if we only use newCapacity.existingNodeLabels, labels which are not existed in new "ExistingNodeLabels" will not be replaced.
Can the existing get*CapacityByLabel can be removed? use queueCapacities#get*capacity instead
null for the queueCapacity ? then we can remove the parameter
Updated setQueueConfig logic, see below
CSQueueUtils.setAbsoluteCapacitiesByNodeLabel may be inside AbstractCSQueue
Now I consolidate all capacities updating fields to CSQueueUtils.loadUpdateAndCheckCapacities
QueueCapacities#getExistingNodeLabels - > getNodeLabels?
It seems getExistingNodeLabels is more expressive to me
why CSQueueUtils.setAbsoluteCapacitiesByNodeLabels(queueCapacities, parent); has to be called in ReservationQueue#reinitialize
I added a grand comment in ReservationQueue to explain why we do this
And in beyond, I found we have ParentQueue/LeafQueue/AbstractCSQueue.setupQueueConfig, there're lots of parameters we need to maintain, it's not simple when we want to add any new (configurable) field to queues, I basically removed all parameters in setupQueueConfig. Instead, all (configurable) fields will be read and initialized from configuration.
Even if we read the Configuration object twice, but I think it doesn't affect performance while reinitializing, and thus we can get simpler structure of queue initialization.
Attached ver.3 patch