hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Shvachko (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-1597) Distributed upgrade status reporting and post upgrade features.
Date Thu, 12 Jul 2007 22:36:05 GMT

     [ https://issues.apache.org/jira/browse/HADOOP-1597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Konstantin Shvachko updated HADOOP-1597:

    Attachment: DistUpgradeStatus2.patch

I slightly changed the way how data-nodes handle missed upgrades.
There is a method in data-node upgrade object preUpgradeAction(),
which determines whether the upgrade is to be started by the data-node
itself or it should wait for the name-node to initiate the upgrade process.
The self-startup happens after the data-node registration but before sending
the first heartbeat. The upgrade object should be able to distinguish whether
the upgrade started by the data-node or by the name-node, since in the former
case the name-node is not expected to receive any upgrade commands.

A also incremented the DatanodeProtocol version, which I forgot to do in my previous patch.

> Distributed upgrade status reporting and post upgrade features.
> ---------------------------------------------------------------
>                 Key: HADOOP-1597
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1597
>             Project: Hadoop
>          Issue Type: New Feature
>          Components: dfs
>    Affects Versions: 0.14.0
>            Reporter: Konstantin Shvachko
>            Assignee: Konstantin Shvachko
>            Priority: Blocker
>             Fix For: 0.14.0
>         Attachments: DistUpgradeStatus.patch, DistUpgradeStatus2.patch
> This patch introduces 2 additional features to the distributed upgrade framework,
> which turned out to be useful for the crc upgrade HADOOP-1134.
> 1. I introduce a DFSAdmin command
> -upgradeProgress status | details | force
> which retrieves current upgrade status, or its detailed status, or forces the upgrade
to proceed if it is stuck.
> 2. If a data-node misses an upgrade it can still join the cluster if the respective upgrade
object implements
> postUpgradeAction() method.
> The framework provides a default implementation of the features.
> For (1) any upgrade object returns by default a generic UpgradeStatusReport class, which
> only the version and the current status of the upgrade.
> An attempt to force the upgrade will have no effect except that the name-node will log
"forceProceed() is not defined"
> For (2) the default implementation leads to a data-node shutdown, which is consistent
with the former behavior.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message