hadoop-yarn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Graves <tgra...@yahoo-inc.com>
Subject Re: Changing LimitedPrivate{"Yarn"}-Evolving interfaces incompatibly
Date Wed, 21 May 2014 13:22:21 GMT
You definitely need to be careful with limitedPrivate as there are some
interfaces tagged with that used by external components/Application
masters.  Some because there are no other alternatives.  My feelings on
limitedPrivate are to remove them and properly mark as either public or
private, see https://issues.apache.org/jira/browse/HADOOP-10506. In the
case of ResourceScheduler.reinitialize I would expect that to be mostly
internal.  There is the possibility someone wrote a specialized scheduler
though.   According to the definition of evolving it should be ok to
change it:
* Evolving, but can break compatibility at minor release (i.e.  m.x)

But if you are just removing an unused parameter perhaps creating a new
method and leave the existing (deprecating it) would be safer.


On 5/19/14, 8:20 PM, "Karthik Kambatla" <kasha@cloudera.com> wrote:

>Hi folks
>Just wanted to understand how kosher it is to change a
>LimitedPrivate{"Yarn"}-Evolving interface in an incompatible way? Do we
>not to change Evolving APIs as much as possible? How about removing an
>unused parameter from a method?
>This is in the context of YARN-1474 changes to ResourceScheduler. I think
>we should change the signature of ResourceScheduler#reinitialize.
>Also, I want to update LimitedPrivate{"Yarn"} to Private.

View raw message