[
https://issues.apache.org/jira/browse/YARN-6596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16301804#comment-16301804
]
Konstantinos Karanasos commented on YARN-6596:
----------------------------------------------
Thanks [~sunilg] for the comments.
bq. When global constraints are added, will it be possible that it may
contradict with some app specific constraints? In that case, how app owner will
know regarding same? I was mentioning about an interface api for app owners to
get the global constrains and based on that place new requests. Please correct
me if I understood this case wrongly.
Good point, yes conflicts can happen. The way I have it in mind is that when
you are to place an application, for a given tag you you will also get the
global constraints. As a follow-up I will create some transformations that will
merge the app-specific and the global constraints. In case of conflicts, I
think we should just deny the placement (or introduce other conflict resolution
strategies, like "the global constraint always wins"). But given the current
API, the application could request the global constraints for this tag instead,
and act accordingly (e.g., relaxing its constraints) to avoid conflicts. Makes
sense?
bq. Map<Set<String>, PlacementConstraint> getConstraints(ApplicationId appId);
looks a bit complicated return value. Its a set of allocation tags
corresponding to one constraint, correct?
A map is actually needed here, because you need a list of pairs from tags to
constraints. Example: you are an HBase app and your first pair is
"hbase-master" -> "node-antiaffinity with hbase-sec", and "hbase-rs" ->
"rack-affinity with hbase-rs".
bq. Multiple source tags to one constraint is not supported in this patch,
correct?
That is right. Initially I was thinking to add support for sets of tags (with a
trie-like data structure), but I think it is better to have a first end-to-end
version without much complications. Once we have that, I will be happy to
extend this. Even in the current version, you could bypass the single-tag
limitation by concatenating tags, but I think in almost all cases single tags
will be sufficient. I kept the API as set of tags though, so that we can easily
extend it.
> Introduce Placement Constraint Manager module
> ---------------------------------------------
>
> Key: YARN-6596
> URL: https://issues.apache.org/jira/browse/YARN-6596
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Konstantinos Karanasos
> Assignee: Konstantinos Karanasos
> Attachments: YARN-6596-YARN-6592.001.patch,
> YARN-6596-YARN-6592.002.patch, YARN-6596-YARN-6592.003.patch
>
>
> This RM module will be responsible for storing placement constraints,
> allocation tags, and node attributes.
> It will be used when determining the placement of SchedulingRequests with
> constraints.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
