Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 18 May 2017 18:27:04 +0000 (UTC)
From: "Panagiotis Garefalakis (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.13071636.1494616019000.243549.1495132024278@Atlassian.JIRA>
In-Reply-To: <JIRA.13071636.1494616019000@Atlassian.JIRA>
References: <JIRA.13071636.1494616019000@Atlassian.JIRA> <JIRA.13071636.1494616019881@jira-lw-us.apache.org>
Subject: [jira] [Commented] (YARN-6593) [API] Introduce Placement Constraint
 object
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 18 May 2017 18:27:09 -0000


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

Panagiotis Garefalakis commented on YARN-6593:
----------------------------------------------

[~kkaranasos] thanks for the patch! 

The discussion totally makes sense to me. Some comments:

*  Totally agree on using a more object oriented way of representing both PlacementConstraint -> CompoundPlacementConstraint/SimplePlacementConstraint and SimplePlacementConstraint -> TargetConstraint/CardinalityConstraint. I think the main value for doing so is usability.
*  Protobuf extentions might also be something we could use. For example:
{code:java}
message TargetConstraintProto {
  extend SimplePlacementConstraintProto
  {
    required TargetConstraintProto costraint = 10; // Unique extension number
  }
}

message CardinalityConstraintProto {
  extend SimplePlacementConstraintProto
  {
    required CardinalityConstraintProto costraint = 11; // Unique extension number
  }
}
{code}

*  We will definitely need a validator implementation - also as a way to ensure users type constraints that do make sense
*  I am also wondering if IN_ANY should be a separate **TargetOperator**  - in a case like C5 design-doc example we would avoid using any TargetValues

Panagiotis


> [API] Introduce Placement Constraint object
> -------------------------------------------
>
>                 Key: YARN-6593
>                 URL: https://issues.apache.org/jira/browse/YARN-6593
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>            Reporter: Konstantinos Karanasos
>            Assignee: Konstantinos Karanasos
>         Attachments: YARN-6593.001.patch
>
>
> This JIRA introduces an object for defining placement constraints.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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