hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Collins (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (HADOOP-8968) add flag to disable completely version check in the TaskTracker and DataNode
Date Thu, 25 Oct 2012 21:15:17 GMT

    [ 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

Mime
View raw message