Stephan Ewen created FLINK-4764:
-----------------------------------
Summary: Introduce config options
Key: FLINK-4764
URL:
https://issues.apache.org/jira/browse/FLINK-4764 Project: Flink
Issue Type: Improvement
Components: Core
Affects Versions: 1.1.2
Reporter: Stephan Ewen
Assignee: Stephan Ewen
Fix For: 1.2.0
It is a bit unorthodox to start a discussion via a pull request, but this suggestion is best motivated via some code.
I suggest to move away from the current model with `ConfigConstants` and move to a model where an `Option` object describes a configuration option completely, with default value, fallback keys.
h2. Advantages
- Much simpler / easier access to values that have deprecated keys
- Not possible to accidentally overlook deprecated keys
- Key and default values are grouped together in the definition
- Clearly states the expected type value for each config key (string, int, etc).
- We can improve this even further to include the description and auto-generate the config docs
h2. Example
Simple option:
{code}
Option<String> TASK_MANAGER_TMP_DIRS = new Option<>(
"taskmanager.tmp.dirs", // config key
System.getProperty("java.io.tmpdir")); // default value
{code}
Option with multiple deprecated keys:
{code}
Option<String> HA_CLUSTER_ID = new Option<>(
"high-availability.cluster-id", // config key
null, // no default value
"high-availability.zookeeper.path.namespace", // latest deprecated key
"recovery.zookeeper.path.namespace"); // even earlier deprecated key
{code}
Get a config value, this automatically checks deprecated keys and default values:
{code}
final String zkQuorum = configuration.getValue(ConfigOptions.HA_ZOOKEEPER_QUORUM);
final long connTimeout = configuration.getInteger(ConfigOptions.HA_ZOOKEEPER_CONN_TIMEOUT);
{code}
h2. Multiple Options classes
To avoid having one huge class (like `ConfigConstants`), we can easily split this up into `TaskManagerOptions`, `JobManagerOptions`, `ZooKeeperOptions`, etc.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Locked
