SPARK-5403: Ignore UserKnownHostsFile in SSH calls

[gdubicki]

See https://issues.apache.org/jira/browse/SPARK-5403

[AmplabJenkins]

Can one of the admins verify this patch?

[cfeduke]

I applied this patch in order to get my Spark cluster on EC2 operational.

[JoshRosen]

Jenkins, this is ok to test.

[SparkQA]

Test build #26120 has started for PR 4196 at commit a7d863f.

• This patch merges cleanly.

[JoshRosen]

I just found another old JIRA asking for the same fix: https://issues.apache.org/jira/browse/SPARK-926. This seems okay to me: we already disable strict host key checking, so I don't think that this change represents a serious security concern.

[SparkQA]

Test build #26120 has finished for PR 4196 at commit a7d863f.

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

[AmplabJenkins]

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

[nchammas]

Hey @grzegorz-dubicki, could you edit the title of this PR and the matching JIRA issue to something more descriptive? Perhaps something like "Ignore UserKnownHostsFile in SSH calls".

There are several possible causes behind spark-ec2 hanging on launch, so it would be good to specify what exactly we're fixing here. The PR and JIRA titles become part of the commit history and release notes, respectively.

[gdubicki]

@nchammas done.

[nchammas]

LGTM.

cc @shivaram

[shivaram]

This sounds reasonable to me. The one downside is that if we don't add it to the known_hosts file then users will be prompted when they try to say ssh into the master instance. Its not a big issue though IMHO

[JoshRosen]

The one downside is that if we don't add it to the known_hosts file then users will be prompted when they try to say ssh into the master instance.

Yeah, this is pretty much the only risk here. If we take the view that we can never create user-observable behavior regressions in maintenance releases, then I think we can only merge this into master and not into the maintenance branches. spark-ec2 is pretty decoupled from the rest of the Spark release, though, so I don't think it's a big deal to not backport this fix to maintenance branches. I think we're probably safe to merge this into master and mention the change in the 1.3.0 release notes. @pwendell, do you agree?

[JoshRosen]

I'm going to merge this into master (1.4.0) and branch-1.3 (1.3.0). I think that this is the right default for most users; if this change causes problems for anyone who depended on the old behavior, we can consider adding a flag for this (or users can just comment out that line themselves, which is a pretty easy workaround).