[
https://issues.apache.org/jira/browse/YARN-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17015404#comment-17015404
]
Wangda Tan edited comment on YARN-9879 at 1/14/20 10:01 PM:
------------------------------------------------------------
[~snemeth], most of the explanation looks reasonable to me. Regarding how to
prevent breaking existing CS queue contract. Instead of adding a flag to each
queue, I suggest to have a global config in CS about allow duplicated leaf
queue name or not.
Why I'm opposed to add the flag to each queue?
To me, use a queue name, or queue path is an intuitive choice of a user (not
admin). If the queue name had duplicates, it should fail and give you the right
reason.
If everybody think we should not implicitly change the CS behavior to allow
duplicate-named leaf queues, a top-level CS config should be sufficient (like
..<cs-prefix>.duplicated-queue-names.allowed), and clearly document it may
cause existing app failures. This won't add any burden for user to understand,
and it is also relatively easy for admin to understand. Anything config added
to the queue hierarchy seems a bit tricky. (Like admin has to think about how
is the queue override looks like, etc.). And for the auto-created queue case it
is not obvious to add such configs, etc.My big lesson learned is we should add
as less knobs as we could, too many knobs will increase our support areas a lot
and make code hard to be maintained.
was (Author: leftnoteasy):
[~snemeth], most of the explanation looks reasonable to me. Regarding how to
prevent breaking existing CS queue contract. Instead of adding a flag to each
queue, I suggest to have a global config in CS about allow duplicated leaf
queue name or not.
Why I'm opposed to add the flag to each queue?
To me, use a queue name, or queue path is an intuitive choice of a user (not
admin). If the queue name had duplicates, it should fail and give you the right
reason.
If everybody think we should not implicitly change the CS behavior to allow
duplicate-named leaf queues, a top-level CS config should be sufficient (like
..<cs-prefix>.duplicated-queue-names.allowed), and clearly document it may
cause existing app failures. This won't add any burden for user to understand,
and it is also relatively easy for admin to understand. Anything config added
to the queue hierarchy seems a bit tricky.
> Allow multiple leaf queues with the same name in CS
> ---------------------------------------------------
>
> Key: YARN-9879
> URL: https://issues.apache.org/jira/browse/YARN-9879
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Gergely Pollak
> Assignee: Gergely Pollak
> Priority: Major
> Attachments: DesignDoc_v1.pdf
>
>
> Currently the leaf queue's name must be unique regardless of its position in
> the queue hierarchy.
> Design doc and first proposal is being made, I'll attach it as soon as it's
> done.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
