What really needs to happen is a metrics-per-partition similar to how node labels were addressed in the scheduler web UI. In the short term I'd probably be OK with the metrics just reflecting the no label case until the per-label metrics work is done. Of course there needs to be TODO comments indicating it's not correct when labels are used.
Looking at the patch closer I think the APIs need to be fixed. Before this patch, CSQueue's setUsedCapacity and setAbsoluteUsedCapacity methods were never called. That makes sense, given that the used capacity of a queue is not something an external entity should be telling the queue. The used capacity naturally falls out of what the queue is doing internally via container allocations and releases, and not because some external entity tells it the used capacity should be X%. I realize it was just a hack to get to the queue's metrics, but it's confusing at best. Given the interfaces aren't used, we should rip those out and eliminate that confusion rather than build on it.
Instead of passing the queue to the CSQueueUtils updating method, I think we can simply pass the queue metrics instead. Then that can update both the QueueCapacities and the QueueMetrics in the same update. The metrics will still be broken for labels as they are today, but we can add a TODO and file a JIRA to fix that going forward. Actually instead of passing the QueueMetrics as an additional parameter, we could pass the CSQueue instead of the QueueCapacities argument and retrieve both the capacities and metrics objects via trivial accessors on the queue. That's what other CSQueueUtils methods are already doing, e.g.: updateQueueStatistics.