Wangda Tan commented on YARN-7920:

{quote}If you don't like priority/placement-optimized, how about calling the 
key "placement strategy" and the values "reject-after-retry" and 
"queue-till-satisfied" where reject implies the processor
This is even worse than {{priority-optimized}} / {{placement-optimized}}, why 
it is important to user to understand a scheduling request will be rejected 
after retry, and this is subject to change as well. I would still prefer the 
"scheduler", "placement-processor" value. Just like the AMS processor config. 

[~sunilg] / [~kkaranasos], could you share your thoughts here?

> Cleanup configuration of PlacementConstraints
> ---------------------------------------------
>                 Key: YARN-7920
>                 URL: https://issues.apache.org/jira/browse/YARN-7920
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>            Priority: Blocker
>         Attachments: YARN-7920.001.patch, YARN-7920.002.patch, 
> YARN-7920.003.patch, YARN-7920.004.patch
> Currently it is very confusing to have the two configs in two different files 
> (yarn-site.xml and capacity-scheduler.xml). 
> Maybe a better approach is: we can delete the scheduling-request.allowed in 
> CS, and update placement-constraints configs in yarn-site.xml a bit: 
> - Remove placement-constraints.enabled, and add a new 
> placement-constraints.handler, by default is none, and other acceptable 
> values are a. external-processor (since algorithm is too generic to me), b. 
> scheduler. 
> - And add a new PlacementProcessor just to pass SchedulingRequest to 
> scheduler without any modifications.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org

Reply via email to