[
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).
{quote}
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?
{quote}
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?
{quote}
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.
{quote}
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
(v6.3.4#6332)
