The intent of the compat guidelines is to prevent developers from making
incompatible "improvements" at inconvenient times. The guidelines offer
some wiggle room for the cases where something truly broken is being
fixed, especially for the sake of compatibility. I would say that in
this case, making the change is the right thing to do, but there needs
to be a plan for how to deal with the fact that the 3.0.0 release will
forever be an odd outlier with respect to NN ports.
Daniel
On 1/8/18 8:28 PM, Aaron T. Myers wrote:
Thanks a lot for the response, Larry. Comments inline.
On Mon, Jan 8, 2018 at 6:44 PM, larry mccay <lmc...@apache.org> wrote:
Question...
Can this be addressed in some way during or before upgrade that allows it
to only affect new installs?
Even a config based workaround prior to upgrade might make this a change
less disruptive.
If part of the upgrade process includes a step (maybe even a script) to
set the NN RPC port explicitly beforehand then it would allow existing
deployments and related clients to remain whole - otherwise it will uptake
the new default port.
Perhaps something like this could be done, but I think there are downsides
to anything like this. For example, I'm sure there are plenty of
applications written on top of Hadoop that have tests which hard-code the
port number. Nothing we do in a setup script will help here. If we don't
change the default port back to what it was, these tests will likely all
have to be updated.
Meta note: we shouldn't be so pedantic about policy that we can't back out
something that is considered a bug or even mistake.
This is my bigger point. Rigidly adhering to the compat guidelines in this
instance helps almost no one, while hurting many folks.
We basically made a mistake when we decided to change the default NN port
with little upside, even between major versions. We discovered this very
quickly, and we have an opportunity to fix it now and in so doing likely
disrupt very, very few users and downstream applications. If we don't
change it, we'll be causing difficulty for our users, downstream
developers, and ourselves, potentially for years.
Best,
Aaron
---------------------------------------------------------------------
To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-dev-h...@hadoop.apache.org
