[
https://issues.apache.org/jira/browse/HDFS-12990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16324589#comment-16324589
]
Chris Douglas commented on HDFS-12990:
--------------------------------------
bq. Can we retract Hadoop 3.0.0 release and restore NN port to 8020 that we
made a bad release? Can this be an alternate approach to produce Hadoop 3.0.1?
No, that's not available.
bq. why not fixing it in 4.0.0 and declare 3.x as dead?
bq. Are there bugs in our current release procedure?
bq. This is a good lesson to avoid time driven release for major version change.
Nah. Even if 3.x were "time driven", [~vinodkv]
[predicted|https://s.apache.org/KnCL] that incompatible changes would require
incompatible fixes, and of course it happened. It _always_ happens, because we
don't control when others try out the release. We don't know how people are
using and extending Hadoop, so we curate compatibility guidelines and
specifications to signal what's intended so applications avoid relying on
incidental behavior. But our guidelines are no more a contract than they are a
suicide pact.
bq. Are we going to have other incompatible changes in the future minor and dot
releases? What is the criteria to decide which incompatible changes are allowed?
I'm sure there are more of these, and we'll remember this issue fondly for
having such a straightforward fix. When an incompatible change is a mistake,
it's a sunk cost. From there, we find the least harmful way to address it and
move on.
We created compatibility guidelines to prioritize users' needs over development
expedience. Reverting the NN port change is consistent with that intent. We
failed to follow our own policy when this change was committed, and absent a
technical justification for this incompatible change, it is a bug. The current
patch restores compatibility.
This needs to converge. Absent a technical justification for the original
change or the veto, and without any alternative approach, the current patch is
the best remedy we have. +1
> Change default NameNode RPC port back to 8020
> ---------------------------------------------
>
> Key: HDFS-12990
> URL: https://issues.apache.org/jira/browse/HDFS-12990
> Project: Hadoop HDFS
> Issue Type: Task
> Components: namenode
> Affects Versions: 3.0.0
> Reporter: Xiao Chen
> Assignee: Xiao Chen
> Priority: Critical
> Attachments: HDFS-12990.01.patch
>
>
> In HDFS-9427 (HDFS should not default to ephemeral ports), we changed all
> default ports to ephemeral ports, which is very appreciated by admin. As part
> of that change, we also modified the NN RPC port from the famous 8020 to
> 9820, to be closer to other ports changed there.
> With more integration going on, it appears that all the other ephemeral port
> changes are fine, but the NN RPC port change is painful for downstream on
> migrating to Hadoop 3. Some examples include:
> # Hive table locations pointing to hdfs://nn:port/dir
> # Downstream minicluster unit tests that assumed 8020
> # Oozie workflows / downstream scripts that used 8020
> This isn't a problem for HA URLs, since that does not include the port
> number. But considering the downstream impact, instead of requiring all of
> them change their stuff, it would be a way better experience to leave the NN
> port unchanged. This will benefit Hadoop 3 adoption and ease unnecessary
> upgrade burdens.
> It is of course incompatible, but giving 3.0.0 is just out, IMO it worths to
> switch the port back.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
