[jira] [Commented] (YARN-12015) Add a Capacity Scheduler queue configuration resolver with explicit inheritance and value sources

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

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

ASF GitHub Bot commented on YARN-12015:
---------------------------------------

brumi1024 opened a new pull request, #8845:
URL: https://github.com/apache/hadoop/pull/8845

   <!--
     Thanks for sending a pull request!
       1. If this is your first time, please read our contributor guidelines: https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute
       2. Make sure your PR title starts with JIRA issue id, e.g., 'HADOOP-17799. Your PR title ...'.
   -->
   
   ### Description of PR
   
   Every per-queue property is declared once as a QueueProperty in QueueProperties: key suffix, parser, applicable queue kinds, resolution steps (queue key, v2 and v1 templates, parent, global key, default) and derivations such as absolute capacity and maximum applications. QueueConfigResolver walks the hierarchy once and produces an immutable ResolvedQueueConfig per queue in which every value records its source; parse failures are kept and rethrown unchanged when the value is read.
   
   CapacitySchedulerConfiguration getters keep their signatures and delegate to the same descriptors against the live configuration, so each default and inheritance rule has one definition. Parity tests compare every getter with the resolver over a set of configurations, including dynamic v1 and v2 queues and reservation queues, and check that configurations trunk rejects keep the same failure.
   
   Leaf queues, plan queues and the derived maximum applications of the resolver share the application limit arithmetic in QueueApplicationLimits, so the derived values cannot drift from the live ones.
   
   
   ### How was this patch tested?
   
   Config loading tests, newly added test cases in YARN-12011, sanity check in a small cluster.
   
   ### For code changes:
   
   - [x] Does the title of this PR start with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
   - [ ] Object storage: Have the integration tests been executed and the endpoint
         declared according to the connector-specific documentation? *Note: Automated CI
         testing doesn't cover all cases so manual testing with cloud storage is still
         required.*
   - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?
   - [ ] If applicable, have you updated the `LICENSE`, `LICENSE-binary`, `NOTICE-binary` files?
   
   ### AI Tooling
   
   If an AI tool was used:
   
   - [x] The PR includes the phrase "Contains content generated by <tool>"
         where <tool> is the name of the AI tool used.
   - [x] My use of AI contributions follows the ASF legal policy
         https://www.apache.org/legal/generative-tooling.html
   
   Contains code generated by Claude Code.




> Add a Capacity Scheduler queue configuration resolver with explicit inheritance and value sources
> -------------------------------------------------------------------------------------------------
>
>                 Key: YARN-12015
>                 URL: https://issues.apache.org/jira/browse/YARN-12015
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacity scheduler
>            Reporter: Benjamin Teke
>            Assignee: Benjamin Teke
>            Priority: Major
>
> Defaults and inheritance rules for queue properties are spread across CapacitySchedulerConfiguration getters, settings classes and queue setup code.
> Declare each per-queue property once (key, parser, applicable queue kinds, resolution chain: queue key, template, parent, global key, default; plus derivations such as absolute capacity and maximum applications) and add QueueConfigResolver, which produces an immutable ResolvedQueueConfig per queue in which every value records its source.
> CapacitySchedulerConfiguration getters keep their signatures and delegate to the same descriptors, so each default and inheritance rule is defined once. Leaf queues, plan queues and the resolver share the maximum applications arithmetic (QueueApplicationLimits). Dynamic queue template values are read like trunk reads them after writing them into the configuration, including variables that reference other template entries. No behavior change should be implemented.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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