Mailing-List: contact yarn-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <140D71EF-F7D6-4D7C-B370-401A8561164E@hortonworks.com>
References: <140D71EF-F7D6-4D7C-B370-401A8561164E@hortonworks.com>
Date: Sat, 28 May 2016 10:07:42 -0700
Message-ID: <CALwhT956PunRg1i_OvKv64NCnNARGRQWwLZ8p5aGhRPrYU173w@mail.gmail.com>
Subject: Re: [DISCUSS] what exactly are the stability guarantees of the YARN APIs
From: Karthik Kambatla <kasha@cloudera.com>
To: Steve Loughran <stevel@hortonworks.com>
Cc: "yarn-dev@hadoop.apache.org" <yarn-dev@hadoop.apache.org>
Content-Type: multipart/alternative; boundary=94eb2c0b0820bc4f420533ea0f93
archived-at: Sat, 28 May 2016 17:07:56 -0000

--94eb2c0b0820bc4f420533ea0f93
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =E2=80=94new abstract methods had been defined, which=
 broke the
> subclasses I have to mock a YARN cluster. These are invaluable classes, a=
s,
> once eventually the hadoop regressions had been worked around, they showe=
d
> 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 =E2=
=80=94are
> marked @Public, @Stable
>
> Given that my code broke, I don't believe that the guarantees of a @Stabl=
e
> interface, "Can evolve while retaining compatibility for minor release
> boundaries; in other words, incompatible changes to APIs marked Stable ar=
e
> 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 thos=
e
> requirements? New methods are going in, some of which are now being tagge=
d
> 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
>
>

--94eb2c0b0820bc4f420533ea0f93--