[
https://issues.apache.org/jira/browse/HADOOP-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019478#comment-14019478
]
Chris Li commented on HADOOP-10376:
-----------------------------------
Hi Arapit,
If we make this feature namenode only, it would remove the requirement to
specify the target, but it would leave certain situations ambiguous, such as
what should happen in the case of HA. I suppose it's a matter of philosophy,
but I wanted to make this intentionally agnostic, so it would work regardless
of what service is targeted, whether HA is enabled for RMs or NNs or other
things are developed in the future.
Perhaps it can offer both? It would ask the user to provide the service to
refresh as host:port, or Namenode/ResourceManager which would refresh on all
the machines in HA or any future configurations such as a quorum. Maybe that's
also another patch.
I'll also switch it back to 1-to-1 mappings, since the added complexity turns
out to be too much after I tried it.
> Refactor refresh*Protocols into a single generic refreshConfigProtocol
> ----------------------------------------------------------------------
>
> Key: HADOOP-10376
> URL: https://issues.apache.org/jira/browse/HADOOP-10376
> Project: Hadoop Common
> Issue Type: Improvement
> Reporter: Chris Li
> Assignee: Chris Li
> Priority: Minor
> Attachments: HADOOP-10376.patch, HADOOP-10376.patch,
> RefreshFrameworkProposal.pdf
>
>
> See https://issues.apache.org/jira/browse/HADOOP-10285
> There are starting to be too many refresh*Protocols We can refactor them to
> use a single protocol with a variable payload to choose what to do.
> Thereafter, we can return an indication of success or failure.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
