[
https://issues.apache.org/jira/browse/YARN-6594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16110276#comment-16110276
]
Jian He edited comment on YARN-6594 at 8/2/17 4:22 AM:
-------------------------------------------------------
Copy some context from YARN-6593
bq. The use-case is to be able to select containers based on key and values,
say, I want to find my containers with version=v1, and env = test, and foo
!=bar and name=web1 or name = web2. These are not used for making scheduling
decisions. But for annotating metaInfo to the containers. We can still make it
work by searching the entire string as Arun said. But that's not explicit. The
AM, client, or even UI then needs to parse the string to extract the keys and
values.
To support this, I probably need to add a separate filed (map) for this, call
it containerTags. and then the allocationTag in this jira can probably be named
as placementTags. (Naming can be figured out later)
The questions is that the allocationTag right now is modeled as set, do we need
to make it as a key/value pair to be consistent ? In any case, a map can
support whatever a set can support, but it's not true the other way around. so
I think it will be more flexible.
I will pursue what I need as containerTags in a separate jira, but thought the
API might be better consistent.
was (Author: jianhe):
Copy some context from YARN-6593
bq. The use-case is to be able to select containers based on key and values,
say, I want to find my containers with version=v1, and env = test, and foo
!=bar and name=web1 or name = web2. These are not used for making scheduling
decisions. But for annotating metaInfo to the containers. We can still make it
work by searching the entire string as Arun said. But that's not explicit. The
AM, client, or even UI then needs to parse the string to extract the keys and
values.
To support this, I probably need to add a separate filed (map) for this, call
it containerTags. and then the allocationTag in this jira can probably be named
as placementTags.
The questions is that the allocationTag right now is modeled as set, do we need
to make it as a key/value pair to be consistent ? In any case, a map can
support whatever a set can support, but it's not true the other way around. so
I think it will be more flexible.
I will pursue what I need as containerTags in a separate jira, but thought the
API might be better consistent.
> [API] Introduce SchedulingRequest object
> ----------------------------------------
>
> Key: YARN-6594
> URL: https://issues.apache.org/jira/browse/YARN-6594
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Konstantinos Karanasos
> Assignee: Konstantinos Karanasos
> Attachments: YARN-6594.001.patch
>
>
> This JIRA introduces a new SchedulingRequest object.
> It will be part of the {{AllocateRequest}} and will be used to define sizing
> (e.g., number of allocations, size of allocations) and placement constraints
> for allocations.
> Applications can use either this new object (when rich placement constraints
> are required) or the existing {{ResourceRequest}} object.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
