[SPARK-6048] SparkConf.translateConfKey should not translate on set

• Type: Bug
• Status: Resolved
• Priority: Blocker
• Resolution: Fixed
• Affects Version/s: 1.3.0
• Fix Version/s: 1.3.0
• Component/s: Spark Core
• Target Version/s: 1.3.0
• Assignee: Andrew Or
• Reporter: Andrew Or
• Created: 27/Feb/15 00:55
• Updated: 09/Apr/15 21:52
• Resolved: 03/Mar/15 00:37

Description

There are several issues with translating on set.

(1) The most serious one is that if the user has both the deprecated and the latest version of the same config set, then the value picked up by SparkConf will be arbitrary. Why? Because during initialization of the conf we call `conf.set` on each property in `sys.props` in an order arbitrarily defined by Java. As a result, the value of the more recent config may be overridden by that of the deprecated one. Instead, we should always use the value of the most recent config.

(2) If we translate on set, then we must keep translating everywhere else. In fact, the current code does not translate on remove, which means the following won't work if X is deprecated:

conf.set(X, Y)
conf.remove(X) // X is not in the conf

This requires us to also translate in remove and other places, as we already do for contains, leading to more duplicate code.

(3) Since we call `conf.set` on all configs when initializing the conf, we print all deprecation warnings in the beginning. Elsewhere in Spark, however, we warn the user when the deprecated config / option / env var is actually being used.
We should keep this consistent so the user won't expect to find all deprecation messages in the beginning of his logs.

Issue Links

• relates to: SPARK-5933 Centralize deprecated configs in SparkConf
• links to: [Github] Pull Request #4799 (andrewor14)