hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <ste...@hortonworks.com>
Subject [DISCUSS] what exactly are the stability guarantees of the YARN APIs
Date Sat, 28 May 2016 10:51:56 GMT

In SLIDER-1130, I discovered that some changes to some YARN classes had broken my test code
—new abstract methods had been defined, which broke the subclasses I have to mock a YARN
cluster. These are invaluable classes, as, once eventually the hadoop regressions had been
worked around, they showed that the label code was broken ( YARN-5135 ) and the fixYARN-4991
not backported to branch-2

If the classes that had changed were tagged as @Private or @Evolving, I'd have just said,
"oh well, never mind"

Except, the two interfaces that broke: ContainerStatus and NodeReport —are marked @Public,

Given that my code broke, I don't believe that the guarantees of a @Stable interface, "Can
evolve while retaining compatibility for minor release boundaries; in other words, incompatible
changes to APIs marked Stable are allowed only at major releases (i.e. at m.0)." are being

Now, in YARN-5130, we now have a patch to remark the interfaces as Unstable.

However, while I can apply that patch myself, I want to raise a broader question: what does
the Yarn team consider constitutes "stable"? 

 And do that changes that took place in YARN-3886 and YARN-2882 meet those requirements? New
methods are going in, some of which are now being tagged as @Evolving?

I fail to see how something marked as @Stable can add @Evolving methods, and given that changes
are breaking downstream code, I worry that not enough care is being taken over the maintenance
of the guarantee which @Public, @Stable interfaces make to users


To unsubscribe, e-mail: yarn-dev-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-dev-help@hadoop.apache.org

View raw message