Arun Suresh commented on YARN-7920:

bq. More likely, the two handler will be merged in the future into the same one 
and user doesn't need to choose.
Agreed that both approaches might merge in the future.
But at the moment, I strongly believe we should give it a more user focused 
value (since end users don't care HOW it is implemented - only what each option 
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 - since the requests 
are rejected if not satisfied in a configurable number of AM heartbeats, while 
the scheduler approach keeps them in queue.

Everything else looks fine.

> 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