[
https://issues.apache.org/jira/browse/YARN-10386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185799#comment-17185799
]
Peter Bacsko edited comment on YARN-10386 at 8/27/20, 11:54 AM:
----------------------------------------------------------------
"Why is the "defaultQueue" property a separate option not a policy?"
That's what I explained, it's confusing. That's intended to set the fallback
default queue, in case a fallback occurs and the {{fallbackResult}} is
{{placeToDefault}}.
"I think we are overusing the defaultQueue in the schema, we should use other
names like, changeDefaultQueue, placeToDefaultQueue, fallbackToDefaultQueue or
something along these lines to make sure it is clear what it will do."
Yep, that's what my first command is about :)
"Nested" is already a policy itself and the "nestedUserRule" is only
interpreted if this particular policy is used.
The reason for a separate nested policy is to prevent users from all kinds of
crazy configurations. Yes, the engine itself can happily resolve stuff like
"root.%default.%primary_group", but I don't think these kind of configurations
should be allowed. So the schema itself takes care of the allowed combinations.
Regarding changing the default, I think it's an overkill to have a separate
changeDefault policy. It's certainly how it works under the hood as an action,
but I don't see too much benefit of exposing this.
was (Author: pbacsko):
"Why is the "defaultQueue" property a separate option not a policy?"
That's what I explained, it's confusing. That's intended to set the fallback
default queue, in case a fallback occurs and the the {{fallbackResult}} is
{{placeToDefault}}.
"I think we are overusing the defaultQueue in the schema, we should use other
names like, changeDefaultQueue, placeToDefaultQueue, fallbackToDefaultQueue or
something along these lines to make sure it is clear what it will do."
Yep, that's what my first command is about :)
"Nested" is already a policy itself and the "nestedUserRule" is only
interpreted if this particular policy is used.
The reason for a separate nested policy is to prevent users from all kinds of
crazy configurations. Yes, the engine itself can happily resolve stuff like
"root.%default.%primary_group", but I don't think these kind of configurations
should be allowed. So the schema itself takes care of the allowed combinations.
Regarding changing the default, I think it's an overkill to have a separate
changeDefault policy. It's certainly how it works under the hood as an action,
but I don't see too much benefit of exposing this.
> Create new JSON schema for Placement Rules
> ------------------------------------------
>
> Key: YARN-10386
> URL: https://issues.apache.org/jira/browse/YARN-10386
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: capacity scheduler, capacityscheduler
> Reporter: Peter Bacsko
> Assignee: Peter Bacsko
> Priority: Major
> Attachments: MappingRulesDescription_v1.json, YARN-10386-001.patch,
> YARN-10386-002.patch, YARN-10386-003.patch, YARN-10386-004.patch,
> YARN-10386-005.patch, YARN-10386-006.patch
>
>
> Tasks in this JIRA:
> # Create new JSON schema
> # Add Maven plugin which generates Java POJOs based on the schema
> # Add helper class which essentially does the same as #2 (for dev purposes)
--
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
