[
https://issues.apache.org/jira/browse/YARN-8013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421128#comment-16421128
]
Weiwei Yang edited comment on YARN-8013 at 3/31/18 1:27 AM:
------------------------------------------------------------
Hi [~kkaranasos]
Thanks for providing your feedback.
{quote}AllocationTagNamespace is slightly misleading
{quote}
That's the best name I came up with so far, I was hoping the java doc explains
the bit (likely not :( )
{noformat}
Class to describe the namespace of an allocation tag.
Each namespace can be evaluated against a set of applications.
After evaluation, the namespace should have an implicit set of applications
which defines its scope.
{noformat}
Any suggested name? The reason I create this class because a tags' scope is
lazy-binding, on the other word, we cannot get the scope during the parsing
phase of a PC expression. That's why we need a eval phase, that can help to
separate different "eval" logic in the different implementation of the
namespace class.
{quote}Why not have a method inside the tags manager that takes an nsScope and
returns only the target applications for that nsScope
{quote}
The best I can do is to move the namespace eval step into allocation tags
manager, that will help to avoid exposing
{{AllocationTagsManager#getApplicationIdToTags}}. The reason I pass in
{{AllocationTags}} instead of just target application IDs to #getCardinality
methods was because when namespace is ALL, it needs to use the global mapping,
which means it needs to know the namespace type of the tags.
{quote}It seems that this will simplify the code of {{TargetApplications}} too.
{quote}
I can even remove this class by letting namespace to be eval'd by two args 1)
current appId 2) all appIds. But I thought this is better encapsulated could be
easier for reading. What do you think?
{quote} perAppNodeMappings.keySet().contains()
{quote}
Fixed.
Thanks
was (Author: cheersyang):
Hi [~kkaranasos]
Thanks for providing your feedback.
{quote}AllocationTagNamespace is slightly misleading
{quote}
That's the best name I came up with so far, I was hoping the java doc explains
the bit (likely not :( )
{noformat}
Class to describe the namespace of an allocation tag. Each namespace can be
evaluated against a set of applications.After evaluation, the namespace should
have an implicit set of applications which defines its scope.
{noformat}
Any suggested name? The reason I create this class because a tags' scope is
lazy-binding, on the other word, we cannot get the scope during the parsing
phase of a PC expression. That's why we need a eval phase, that can help to
separate different "eval" logic in the different implementation of the
namespace class.
{quote}Why not have a method inside the tags manager that takes an nsScope and
returns only the target applications for that nsScope
{quote}
The best I can do is to move the namespace eval step into allocation tags
manager, that will help to avoid exposing
\{{AllocationTagsManager#getApplicationIdToTags}}. The reason I pass in
\{{AllocationTags}} instead of just target application IDs to #getCardinality
methods was because when namespace is ALL, it needs to use the global mapping,
which means it needs to know the namespace type of the tags.
{quote}It seems that this will simplify the code of {{TargetApplications}} too.
{quote}
I can even remove this class by letting namespace to be eval'd by two args 1)
current appId 2) all appIds. But I thought this is better encapsulated could be
easier for reading. What do you think?
{quote} perAppNodeMappings.keySet().contains(){quote}
Fixed.
Thanks
> Support APP-TAG namespace for allocation tags
> ---------------------------------------------
>
> Key: YARN-8013
> URL: https://issues.apache.org/jira/browse/YARN-8013
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Weiwei Yang
> Assignee: Weiwei Yang
> Priority: Major
> Attachments: YARN-8013.001.patch, YARN-8013.002.patch,
> YARN-8013.003.patch, YARN-8013.004.patch
>
>
> YARN-1461 adds *Application Tag* concept to Yarn applications, user is able
> to annotate application with multiple tags to classify apps. We can leverage
> this to represent a namespace for a certain group of apps. So instead of
> calling *app-label*, propose to call it *app-tag*.
> A typical use case is,
> There are a lot of TF jobs running on Yarn, and some of them are consuming
> resources heavily. So we want to limit number of PS on each node for such BIG
> players but ignore those SMALL ones. To achieve this, we can do following
> steps:
> # Add application tag "big-tf" to these big TF jobs
> # For each PS request, we add "ps" source tag and map it to constraint
> "{color:#d04437}notin, node, tensorflow/ps{color}" or
> "{color:#d04437}cardinality, node, tensorflow/ps{color}{color:#d04437}, 0,
> 2{color}" for finer grained controls.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
