General - it looks like the counters could possibly overflow and provide negative values, perhaps this is not something which could possibly happen in the lifetime of a cluster, but a large long-running cluster, is it a possiblilty/concern?
The counters in SchedulerHealth are Long so it should be fine. The counters in AssignmentInformation(new class I added) are reset every allocation cycle.
This presently looks to be capasched only, had a suggestion to make slightly more general below, Vinod Kumar Vavilapalli also mentioned "not specific to scheduler", perhaps it's fine to go capasched only for the first iteration, but wanted to verify (perhaps we need a followon jira for other schedulers).
Yes. That's the plan - once it's in for CapacityScheduler, I'll file a ticket to add the information for FairScheduler and point to this one as an example of the stuff we added.
on the web page
It's a nit, but I find I don't like the look of the / between the counter and the resource expression where that occurs, maybe - instead of / for those (allocations/reservations/releases)?
can we import Nodemanager & get rid of package references in code
looks like there is no need to keep a reference to the CapacityScheduler instance after construction, can we drop it from being a member then?
looks like line changes in info log are just whitespace, can you drop them?
L884 looks to be just whitespace, can you revert?
I think that there should be a new, gsharable between schedulers class which incorporates all the new assignment info and that it should be a member of CSAssignment, instead of adding all of the details directly to CSAssignment. You would still pack the info into CSAssignment (as an instance of that type), but now would take a form that can be shared across schedulers
Fixed. I created a new class called AssignmentInformation which encapsulates everything.