[jira] [Updated] (HDFS-3084) FenceMethod.tryFence() and ShellCommandFencer should pass namenodeId as well as host:port

["Todd Lipcon (Updated) (JIRA)" <ji...@apache.org>]

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

Todd Lipcon updated HDFS-3084:
------------------------------

    Attachment: hdfs-3084.txt

This patch, in conjunction with HADOOP-8007, provides the necessary facilities:

- the configuration used to instantiate the NodeFencer is now the configuration of the _target_ node, rather than the _fencing_ node. This means that all of the configs like RPC address have already had the nameservice and namenodeid chopped off
- in addition to the variables described in HADOOP-8007, we add $target_namenodeid and $target_nameserviceid to the fencing environment
- added getters for namenode id and nameservice id to NNHAServiceTarget. If a custom fencing implementation is HDFS specific, it can downcast to the implementation class to access these getters. Alternatively, it may call {{getFencingParameters()}} and then use the resulting string map to get at this info.

The patch depends on HADOOP-8007. I'll submit it to QA once that other patch is committed.
                
> FenceMethod.tryFence() and ShellCommandFencer should pass namenodeId as well as host:port
> -----------------------------------------------------------------------------------------
>
>                 Key: HDFS-3084
>                 URL: https://issues.apache.org/jira/browse/HDFS-3084
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: ha
>    Affects Versions: 0.24.0, 0.23.3
>            Reporter: Philip Zeyliger
>            Assignee: Todd Lipcon
>         Attachments: hdfs-3084.txt
>
>
> The FenceMethod interface passes along the host:port of the NN that needs to be fenced.  That's great for the common case.  However, it's likely necessary to have extra configuration parameters for fencing, and these are typically keyed off the nameserviceId.namenodeId (if, for nothing else, consistency with all the other parameters that are keyed off of namespaceId.namenodeId).  Obviously this can be backed out from the host:port, but it's inconvenient, and requires iterating through all the configs.
> The shell interface exhibits the same issue: host:port is great for most fencers, but if you need extra configs (like the host:port of the power supply unit), those are harder to pipe through without the namenodeId.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira