[
https://issues.apache.org/jira/browse/HDFS-5585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896144#comment-13896144
]
Brandon Li commented on HDFS-5585:
----------------------------------
[~kihwal], thanks for the new patch.
Here is my understanding of how these two new CLIs could be used in a rolling
upgrade procedure. Suppose only the datanodes need to be upgraded:
1. The user could issue the CLI "shutdownDatanode -upgrade" first to trigger
the datanode rolling upgrade procedure.
2. Then the user uses getDatanodeInfo to pull datanode status to know if it's
still alive.
3. once the datanode is successfully shutdown, restart it to upgrade
4. after datanode is started, use getDatanodeInfo to verify the new layout
version and so on.
However, for step 2, checking datanode process id status can better confirm
datanode process' aliveness. For step 4, part of the new datanode version
information can also be retrieved by asking namenode, in UI or "dfsadmin
-report".
So the question is, could it be better to just enhance "dfsadmin -report" to
include datanode layout/software versions than introduce the new CLI
getDatanodeInfo?
> Provide admin commands for data node upgrade
> --------------------------------------------
>
> Key: HDFS-5585
> URL: https://issues.apache.org/jira/browse/HDFS-5585
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: datanode, ha, hdfs-client, namenode
> Reporter: Kihwal Lee
> Assignee: Kihwal Lee
> Attachments: HDFS-5585.patch, HDFS-5585.patch, HDFS-5585.patch
>
>
> Several new methods to ClientDatanodeProtocol may need to be added to support
> querying version, initiating upgrade, etc. The admin CLI needs to be added
> as well. This primary use case is for rolling upgrade, but this can be used
> for preparing for a graceful restart of a data node for any reasons.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
