hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangjin Lee (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3039) [Aggregator wireup] Implement ATS app-appgregator service discovery
Date Fri, 13 Mar 2015 23:03:40 GMT

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

Sangjin Lee commented on YARN-3039:

[~djp], a couple of quick comments (I'll follow up after reviewing the latest patch more carefully).

We could have an annotation in class level which is default publicity and stability for each
method. However, each method could have its own annotation to override the class one. In most
cases, the class level annotation is more public and stable than individual methods which
is first-class contract with end users or other components (or they will have concerns to
use it). Take an example, if we need to add a new API which is not stable yet to a protocol
class marked with stable, we shouldn't regression the whole class from stable to evolving
or unstable, but we can mark the new method as unstable or evolving. Make sense?

Yes, I get the reasoning for annotating individual methods. My concern is more about the *new
classes*. Note that we're still evolving even the class names. This might be a fine point,
but I feel we should annotate the *new classes* at least as unstable for now in addition to
the method annotations. Thoughts?

bq. RMAppImpl.java, Would this be backward compatible from the RM state store perspective?
I don't think so. ApplicationDataProto is also be a protobuffer object, and new field for
aggreagtorAddress is optional.

So you mean it will be backward compatible, right?

> [Aggregator wireup] Implement ATS app-appgregator service discovery
> -------------------------------------------------------------------
>                 Key: YARN-3039
>                 URL: https://issues.apache.org/jira/browse/YARN-3039
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Sangjin Lee
>            Assignee: Junping Du
>         Attachments: Service Binding for applicationaggregator of ATS (draft).pdf, Service
Discovery For Application Aggregator of ATS (v2).pdf, YARN-3039-no-test.patch, YARN-3039-v2-incomplete.patch,
YARN-3039-v3-core-changes-only.patch, YARN-3039-v4.patch, YARN-3039-v5.patch
> Per design in YARN-2928, implement ATS writer service discovery. This is essential for
off-node clients to send writes to the right ATS writer. This should also handle the case
of AM failures.

This message was sent by Atlassian JIRA

View raw message