[
https://issues.apache.org/jira/browse/YARN-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14526205#comment-14526205
]
Dian Fu commented on YARN-3557:
-------------------------------
Hi [~leftnoteasy] & [~Naganarasimha],
Thanks a lot for your review and comments.
{quote}Scheduler doesn't need to know if a node is trusted or not, "trusted"
will be a generic label of a node{quote}
Yes. This scenario can be seen as a use case of label feature.
{quote}Now RM supports using CLI or REST API, are they enough for you to
configure NM's "trusted" status?{quote}
Yes, RM supports using CLI and REST API, but these APIs require the admin
permission and from my point of view, these APIs are more suitable for the
scenarios in which admin knows when the labels of nodes should be modified, is
this correct? While in the scenario described in this JIRA, admin don't know
when the security label of the nodes change, so periodical security check need
to be performed and the labels may change at any time.
{quote}Configure both could be problematic, see my comment:
https://issues.apache.org/jira/browse/YARN-2495?focusedCommentId=14317048&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14317048.{quote}
I agree with you that configure both may be problematic for the example you
described. I'm thinking if we can make some labels configured in centralized
way and some labels configured in distributed way? For the same label it can
only be configured in one method.
Support both configurations may be necessary as some labels may require
centralized configuration be used such as the label in this use case and some
labels may require distributed configuration. It's very likely that some use
cases may require both these two kinds of labels.
{quote}Did you mean NM here ? RM side configure is already there and NM side
(distributed) is almost done and might be available in 2.8.{quote}
I mean RM here. As in the security label use case, NM may be running on
untrustworthy nodes. So we cannot trust the security lables NM reported.
{quote}If you have selected the 2nd option RM retrieve the trust status of all
cluster nodes from OAT, then why is it dependent on YARN-2495 & support to
configure centralized node label configuration or distributed node label
configuration required ? {quote}
It isn't dependent on YARN-2495. I mean we may need some methods to configure
node labels in RM side which can use similar methods in YARN-2495. Sorry to let
you misunderstand.
> Support Intel Trusted Execution Technology(TXT) in YARN scheduler
> -----------------------------------------------------------------
>
> Key: YARN-3557
> URL: https://issues.apache.org/jira/browse/YARN-3557
> Project: Hadoop YARN
> Issue Type: New Feature
> Reporter: Dian Fu
> Attachments: Support TXT in YARN high level design doc.pdf
>
>
> Intel TXT defines platform-level enhancements that provide the building
> blocks for creating trusted platforms. A TXT aware YARN scheduler can
> schedule security sensitive jobs on TXT enabled nodes only. YARN-2492
> provides the capacity to restrict YARN applications to run only on cluster
> nodes that have a specified node label. This is a good mechanism that be
> utilized for TXT aware YARN scheduler.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
