[
https://issues.apache.org/jira/browse/HADOOP-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467721
]
Raghu Angadi commented on HADOOP-702:
-------------------------------------
I vote against requiring strict build version match between datanodes and
namenode.. especially if it results in datanodes being marked dead in case of
mismatch. Unless there is an easy way to disable,
1) In practice its hard to make sure every node is running the same software
version ALL the time. Pretty soon we might a have case we forgot or rsync
failed to push to half the nodes and name nodes suddenly looses a large chunk
of data as a result.
2) As Konstantin mentioned, even in a test cluster this makes active testing
hard. If i am working on a small namenode feature on not so small test cluster,
it would require me to push new software and restart the whole cluster many
times, also increasing possibility of (1).
> DFS Upgrade Proposal
> --------------------
>
> Key: HADOOP-702
> URL: https://issues.apache.org/jira/browse/HADOOP-702
> Project: Hadoop
> Issue Type: New Feature
> Components: dfs
> Reporter: Konstantin Shvachko
> Assigned To: Konstantin Shvachko
> Attachments: DFSUpgradeProposal.html, DFSUpgradeProposal2.html,
> DFSUpgradeProposal3.html, FSStateTransition.html, TestPlan-HdfsUpgrade.html,
> TestPlan-HdfsUpgrade.html
>
>
> Currently the DFS cluster upgrade procedure is manual.
> http://wiki.apache.org/lucene-hadoop/Hadoop_Upgrade
> It is rather complicated and does not guarantee data recoverability in case
> of software errors or administrator mistakes.
> This is a description of utilities that make the upgrade process almost
> automatic and minimize chance of loosing or corrupting data.
> Please see the attached html file for details.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
