[
https://issues.apache.org/jira/browse/HADOOP-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484490#comment-13484490
]
Eli Collins edited comment on HADOOP-8968 at 10/25/12 9:15 PM:
---------------------------------------------------------------
@Tucu, on the TT side, under what scenario could an experimental patch result
in a build version that matches but a version that does not? The build version
string should _contain_ the version string, ie you'd have to manually edit the
version info object for that not to be the case. On the DN side you could
construct a build with matching revisions but not versions if you build from
the same exact source but use different version strings, but I don't see why
anyone would do this. For example, if you're doing an experimental patch then
the builds would have different revisions, and to trigger this assert you need
to match revisions but not versions. If we think these checks should in fact
fire in cases we should make them runtime errors instead of assertion errors
(which are intended for cases that should not happen), but I don't see any
valid scenario where we'd hit them.
@Suresh, correct, this patch adds an option to turn off the version match
completely, ie the version string (with the embedded major, minor, point
version) is ignored. V1 workers obviously can't connect to v2, and since we're
not doing another major release off branch-1 the only way you could get a DN/TT
to try connect to a different major version is to enable this option and use
DNs/TTs from a 1.2.x build and have a NN or JT from a 0.20 build.
was (Author: eli):
@Tucu, on the TT side, under what scenario could an experimental patch
result in a build version that matches but a version that does not? The build
version string should _contain_ the version string, ie you'd have to manually
edit the version info object for that not to be the case. On the DN side you
could construct a build with matching revisions but not versions if you build
from the same exact source but use different version strings, but I don't see
why anyone would do this. For example, if you're doing an experimental patch
then the builds would have different revisions, and to trigger this assert you
need to match revisions but not versions. If we think these checks should in
fact fire in cases we should make them runtime errors instead of assertion
errors (which are intended for cases that should not happen), but I don't see
any valid scenario where we'd hit them.
@Suresh, correct, this patch adds an option to turn off the version match
completely, ie the version string (with the embedded major, minor, point
version) is ignored. V1 workers obviously can't connect to v2, and since we're
not doing another major release off branch-1 the only way you could get a DN/TT
to try connect to a different major version is to enable this option and use
DNs/TTs from a 1.1.x build and have a NN or JT from a 0.20 build.
> add flag to disable completely version check in the TaskTracker and DataNode
> ----------------------------------------------------------------------------
>
> Key: HADOOP-8968
> URL: https://issues.apache.org/jira/browse/HADOOP-8968
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 1.1.0
> Reporter: Alejandro Abdelnur
> Assignee: Alejandro Abdelnur
> Fix For: 1.2.0
>
> Attachments: HADOOP-8968.patch, HADOOP-8968.patch, HADOOP-8968.patch
>
>
> The current logic in the TaskTracker and the DataNode to allow a relax
> version check with the JobTracker and NameNode works only if the versions of
> Hadoop are exactly the same.
> We should add a switch to disable version checking completely, to enable
> rolling upgrades between compatible versions (typically patch versions).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
