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

Wangda Tan commented on YARN-2986:
----------------------------------

Thanks for [~vinodkv] reporting, a huge +1 for the proposal.

*In addition to Vinod's suggest, I think we should define scheduler conf 
standard first, my proposal is*

{code}
<scheduler>
   <global-option1>value</global-option1>
   <global-option2>value</global-option2>
   <global-option3>value</global-option3>

   <queue name="root">
      <state>running</state>

      <queue-option1>value</queue-option1>
      <queue-option2>value</queue-option2>
      <queue-option3>value</queue-option3>

      <queue name="a">
         <state>running</state>

         <queue name="a1">
                ...
         </queue>
      </queue>

      <queue name="b">
        ...
      </queue>
   </queue>
</scheduler>
{code}

There're several things need to be highlight in above example:
1) There's no "group xml node", instead of
{code}
<children>
        <queue name=1/>
        <queue name=2/>
<children>
{code}

or 
{code}
<scheduler-custom-configuration>
    <!-- Scheduler specific global configuration -->
    <!-- For e.g.
      <maximum-applications>10000</maximum-applications>
      <resource-calculator>DominantResourceCalculator</resource-calculator>
    -->
  </scheduler-custom-configuration>
{code}

I would suggest
{code}
<queue name=1/>
<queue name=2/>
{code}

2) Element vs. Attribute
(Definition of E/A, see http://www.w3schools.com/xml/xml_attributes.asp)
I think we shouldn't mix element/attribute in config file, attribute field 
should be only a limited set of properties. IMO, name/type should be only 
properties that need to put as attribute.
With this, admin will not hesitate about which property needs go to attribute 
and which needs to go Element.

*To Implement this, I think there're two steps:*

1) A parser to support easily get/set values for scheduler conf.
- Hide complexities of a generic XML parser
- Have basic functionalities to handle value inherit, etc.
For each level ({{<key>...</key>}}), data structure could as simple as:
{code}
SchedulerConfNode {
        String getName();
        String getType();
        String get(String key, bool inherit=false, default=null);
        List<Node> getChildren(String key);
}
{code}

2) Common implementation of existing Hadoop scheduler
Since there're some fields common in fair/capacity/fifo scheduler, we can 
extend the {{SchedulerConfNode}} to {{BaseSchedulerConfNode}}, which has more 
methods like:
{code}
BaseSchedulerConfNode : SchedulerConfNode {
        Resource getMinimumAllocation();
        Resource getMaximumAllocation();
        List<String> getSubmitAcls();
        // ...
}
{code}

Thoughts?

> Support hierarchical and unified scheduler configuration
> --------------------------------------------------------
>
>                 Key: YARN-2986
>                 URL: https://issues.apache.org/jira/browse/YARN-2986
>             Project: Hadoop YARN
>          Issue Type: Improvement
>            Reporter: Vinod Kumar Vavilapalli
>            Assignee: Vinod Kumar Vavilapalli
>
> Today's scheduler configuration is fragmented and non-intuitive, and needs to 
> be improved. Details in comments.



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

Reply via email to