[
https://issues.apache.org/jira/browse/HADOOP-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924832#action_12924832
]
Todd Lipcon commented on HADOOP-7001:
-------------------------------------
I'm not sold on the interface being one of "set conf var 'foo' to value 'bar'".
Internally, this seems fine, but exposing this as a servlet seems like it will
encourage the case where runtime configuration diverges from what's in the XML
configuration files on disk.
Could we instead have the servlet/API be more similar to the existing refresh*
functions, where it reloads the configuration off disk, and applies a diff? I'm
imagining the servlet would show you a "preview" of the diff to be applied,
along with a list of warnings for configuration variables that have been
changed on disk but are *not* reconfigurable. Then the administrator can hit an
"apply" button to reconfigure the settings that are reconfigurable.
> Allow configuration changes without restarting configured nodes
> ---------------------------------------------------------------
>
> Key: HADOOP-7001
> URL: https://issues.apache.org/jira/browse/HADOOP-7001
> Project: Hadoop Common
> Issue Type: Task
> Reporter: Patrick Kling
> Assignee: Patrick Kling
> Attachments: HADOOP-7001.2.patch, HADOOP-7001.patch,
> reconfigurable.patch
>
>
> Currently, changing the configuration on a node (e.g., the name node)
> requires that we restart the node. We propose a change that would allow us to
> make configuration changes without restarting. Nodes that support
> configuration changes at run time should implement the following interface:
> interface ChangeableConfigured extends Configured {
> void changeConfiguration(Configuration newConf) throws
> ConfigurationChangeException;
> }
> The contract of changeConfiguration is as follows:
> The node will compare newConf to the existing configuration. For each
> configuration property that is set to a different value than in the current
> configuration, the node will either adjust its behaviour to conform to the
> new configuration or throw a ConfigurationChangeException if this change is
> not possible at run time. If a configuration property is set in the current
> configuration but is unset in newConf, the node should use its default value
> for this property. After a successful invocation of changeConfiguration, the
> behaviour of the configured node should be indistinguishable from the
> behaviour of a node that was configured with newConf at creation.
> It should be easy to change existing nodes to implement this interface. We
> can start by throwing the exception for all changes and then gradually start
> supporting more and more changes at run time. (We might even consider
> replacing Configured with ChangeableConfigured entirely, but I think the
> proposal above afford greater flexibility).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
