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 
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

Reply via email to