[ 
https://issues.apache.org/jira/browse/YARN-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14596481#comment-14596481
 ] 

Jian He commented on YARN-1963:
-------------------------------

I think we need to move this forward..

Overall, I prefer using numeric priority to label-based priority because the 
former is simpler and more flexible if user wants to define a wide range of 
priorities. no extra configs. User does not need to be educated about the new 
mapping any time the mapping changes.

Also, one problem is that if we refresh the priority mapping while some 
existing long-running jobs are already running on certain priority, how do we 
map the previous priority mapping range to the new priority mapping range?

In addition, if everyone runs the application at “VERY_HIGH” priority, the 
“HIGH” priority, though named as “HIGH”, is not really the “HIGH” priority any 
more. It actually becomes the “LOWEST” priority. My point is that the 
importance of priority will make sense only when compared with its peers. In 
that sense, I think adding a utility to surface how applications are 
distributed across each priority so that user can reason about how to place the 
application on certain priority may be more useful than adding a static naming 
mapping to let people reason about the relative importance of priority by 
naming. 

> Support priorities across applications within the same queue 
> -------------------------------------------------------------
>
>                 Key: YARN-1963
>                 URL: https://issues.apache.org/jira/browse/YARN-1963
>             Project: Hadoop YARN
>          Issue Type: New Feature
>          Components: api, resourcemanager
>            Reporter: Arun C Murthy
>            Assignee: Sunil G
>         Attachments: 0001-YARN-1963-prototype.patch, YARN Application 
> Priorities Design.pdf, YARN Application Priorities Design_01.pdf
>
>
> It will be very useful to support priorities among applications within the 
> same queue, particularly in production scenarios. It allows for finer-grained 
> controls without having to force admins to create a multitude of queues, plus 
> allows existing applications to continue using existing queues which are 
> usually part of institutional memory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to