Thanks for updating the patch, Sunil!
I'm not sure why we need an updateJobPriority that's separate from the existing setJobPriority call that's already there. Seems like we just need to put the code for updateApplicationPriority into ResourceMgrDelegate.setJobPriority which currently does nothing.
Why does setJobPriority return DEFAULT if the priority appears to be a negative number but returns UNDEFINED_PRIORITY if the number is not negative? I don't recall negative priority values being special.
We need to translate equivalent integer priorities to the corresponding enum. For example, if someone sets the priority as 5 then getJobPriority should return VERY_HIGH. Otherwise when someone sets a priority via enum they will get back UNDEFINED_PRIORITY instead of what they set which is inconsistent.
Job.setPriority should preserve the enum name in the conf for better backwards compatibility. I think we should pass the Job.setPriority argument straight through JobConf.setJobPriority if the enum isn't UNDEFINED_PRIORITY.
TypeConverter needs to handle the new DEFAULT priority as zero.
Nit: Please add comments to the two new JobPriority enums explaining their usage.
The handling of priority from JobStatus also needs to be updated. Currently the code is hardwired to return a NORMAL priority for a running job. See the way TypeConverter handles an application report and builds up a job status.
There should be some unit tests. Minimally there should be tests to check some of the things we've discussed wrt. consistency of priority get and set. For example, setting a priority enum should return that enum on get for the old priority enums, etc. There should also be a test that verifies we are passing the priority in the app submission context appropriately and calling the appropriate API to update job priority when job.setPriority is called on a running job. Finally there should be tests to verify we are marshalling a YARN application report properly wrt. priority handling.