[
https://issues.apache.org/jira/browse/YARN-6593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015028#comment-16015028
]
Konstantinos Karanasos edited comment on YARN-6593 at 5/18/17 1:13 AM:
-----------------------------------------------------------------------
Thanks for the comments guys.
So, we all agree on the validator, will open a JIRA to track this.
+1 on having a string representation and a library to convert it to
constraints. I think it will become very useful soon, but agreed it is not
urgent.
Self-reference works fine even with the current protobuf version. I think I saw
a single use of it in our yarn_protos (I think it was in the QueueInfo or
something related).
That said, both approaches make sense to me.
I guess the approach in the current patch is a little bit more cumbersome to
right (we will have one extra call to create a PlacementConstraint). Is that
its disadvantage or there is something else too?
On the other hand, what I don't like if we coalesce the two, is that (1) the
proto becomes too complicated (and I am afraid we will be the only ones
understanding it :)), and (2) the client will still have access to very
unrelated getters and setters. For example, the user could be creating a
CompoundConstraint and have access to a getTargetExpression() function.
was (Author: kkaranasos):
Thanks for the comments guys.
So, we all agree on the validator, will open a JIRA to track this.
+1 on having a string representation and a library to convert it to
constraints. I think it will become very useful soon, but agreed it is not
urgent.
Self-reference works fine even with the current protobuf version. I think I saw
a single use of it in our yarn_protos (I think it was in the QueueInfo or
something related).
That said, both approaches make sense to me.
I guess the approach in the current JIRA is a little bit more cumbersome to
right (we will have one extra call to create a PlacementConstraint). Is that
its disadvantage or there is something else too?
On the other hand, what I don't like if we coalesce the two, is that (1) the
proto becomes too complicated (and I am afraid we will be the only ones
understanding it :)), and (2) the client will still have access to very
unrelated getters and setters. For example, the user could be creating a
CompoundConstraint and have access to a getTargetExpression() function.
> [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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
