hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karthik Kambatla <ka...@cloudera.com>
Subject Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs
Date Sat, 28 May 2016 17:07:42 GMT
Inline.

On Sat, May 28, 2016 at 3:51 AM, Steve Loughran <stevel@hortonworks.com>
wrote:

>
> 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, @Stable
>
> 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 kept.
>
> 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
>

Are you referring to adding @Evolving methods to @Stable classes? If yes,
my understanding is - the annotations are per-method and the class
annotations are a convenience to avoid having to annotate each method.


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message