Skip to content

Conversation

@andrewor14
Copy link
Contributor

There are multiple issues with translating on set outlined in the JIRA.

This PR reverts the translation logic added to SparkConf. In the future, after the 1.3.0 release we will figure out a way to reorganize the internal structure more elegantly. For now, let's preserve the existing semantics of SparkConf since it's a public interface. Unfortunately this means duplicating some code for now, but this is all internal and we can always clean it up later.

@SparkQA
Copy link

SparkQA commented Feb 27, 2015

Test build #28029 has started for PR 4799 at commit 94b4dfa.

  • This patch merges cleanly.

@andrewor14
Copy link
Contributor Author

cc @vanzin who originally wrote this code

@SparkQA
Copy link

SparkQA commented Feb 27, 2015

Test build #28029 has finished for PR 4799 at commit 94b4dfa.

  • This patch fails Spark unit tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28029/
Test FAILed.

@pwendell
Copy link
Contributor

@vanzin does this look okay to you? I commented on the JIRA, but my main goal is to find a surgical patch here that can unblock the release, so just rewinding the change seems the safest.

@SparkQA
Copy link

SparkQA commented Feb 27, 2015

Test build #28037 has started for PR 4799 at commit fef6c9c.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Feb 27, 2015

Test build #28037 has finished for PR 4799 at commit fef6c9c.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28037/
Test PASSed.

@SparkQA
Copy link

SparkQA commented Feb 28, 2015

Test build #28104 has started for PR 4799 at commit c26a9e3.

  • This patch merges cleanly.

@vanzin
Copy link
Contributor

vanzin commented Feb 28, 2015

Given the discussion on the bug it looks ok, but it's missing the documentation that explains the behavior.

@SparkQA
Copy link

SparkQA commented Feb 28, 2015

Test build #28104 has finished for PR 4799 at commit c26a9e3.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28104/
Test PASSed.

@pwendell
Copy link
Contributor

pwendell commented Mar 1, 2015

I agree @andrewor14 can you add documentation about deprecated configs?

I would extend what's there now:

Properties set directly on the SparkConf take highest precedence, then 
flags passed to spark-submit or spark-shell, then options in the 
spark-defaults.conf file. A few configuration keys have been renamed
since earlier versions of Spark; in such cases, the older key names are still
accepted, but take lower precedence than any instance of the newer key.

@SparkQA
Copy link

SparkQA commented Mar 1, 2015

Test build #28143 has started for PR 4799 at commit 10e77b5.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Mar 1, 2015

Test build #28143 has finished for PR 4799 at commit 10e77b5.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28143/
Test PASSed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will log it on the executors, which seems weird since all other configuration warnings are logged at the driver or submission client. Can we just log this warning on the driver side? Or just don't log a deprecation warning always?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is your proposal to not log this warning, or log it on the driver side?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Log it on the driver side during validation, or at some earlier point. I just think having it here isn't super useufl.

@SparkQA
Copy link

SparkQA commented Mar 2, 2015

Test build #28178 has started for PR 4799 at commit 11c525b.

  • This patch merges cleanly.

@SparkQA
Copy link

SparkQA commented Mar 2, 2015

Test build #28178 has finished for PR 4799 at commit 11c525b.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@AmplabJenkins
Copy link

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/28178/
Test PASSed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you're doing this only once during the app's lifetime (this method is only called from SparkContext AFAICT), you could simplify the code that tracks whether warns have been printed in DeprecatedConfig. But ok to not do it if you want to limit the scope of the change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah let's revamp this whole thing after the release

@vanzin
Copy link
Contributor

vanzin commented Mar 2, 2015

LGTM, left just minor comments.

@pwendell
Copy link
Contributor

pwendell commented Mar 3, 2015

Okay - thanks everyone for helping with this. I'll pull it in.

asfgit pushed a commit that referenced this pull request Mar 3, 2015
There are multiple issues with translating on set outlined in the JIRA.

This PR reverts the translation logic added to `SparkConf`. In the future, after the 1.3.0 release we will figure out a way to reorganize the internal structure more elegantly. For now, let's preserve the existing semantics of `SparkConf` since it's a public interface. Unfortunately this means duplicating some code for now, but this is all internal and we can always clean it up later.

Author: Andrew Or <andrew@databricks.com>

Closes #4799 from andrewor14/conf-set-translate and squashes the following commits:

11c525b [Andrew Or] Move warning to driver
10e77b5 [Andrew Or] Add documentation for deprecation precedence
a369cb1 [Andrew Or] Merge branch 'master' of github.com:apache/spark into conf-set-translate
c26a9e3 [Andrew Or] Revert all translate logic in SparkConf
fef6c9c [Andrew Or] Restore deprecation logic for spark.executor.userClassPathFirst
94b4dfa [Andrew Or] Translate on get, not set

(cherry picked from commit 258d154)
Signed-off-by: Patrick Wendell <patrick@databricks.com>
@asfgit asfgit closed this in 258d154 Mar 3, 2015
@andrewor14 andrewor14 deleted the conf-set-translate branch March 3, 2015 00:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants