Construct shell commands as sequences for safety and composability
Generate new SSH key for the cluster, make "--identity-file" optional
Clarify error messages on SSH failure
Start of working on SPARK-615
Make mapPartitionsWithIndex work with JavaRDD's
Merge branch 'master' of https://github.com/mesos/spark
Fix build on ubuntu
Switch indent from 2 to 4 spaces
Fix formatting :)
Improved organization of scheduling packages.

This commit does not change any code -- only file organization.

There are two components of this change:
(1) Moving files out of the cluster package, and down
a level to the scheduling package. These files are all used by
the local scheduler in addition to the cluster scheduler(s), so
should not be in the cluster package. As a result of this change,
none of the files in the local package reference files in the
cluster package.

(2) Moving the mesos package to within the cluster package.
The mesos scheduling code is for a cluster, and represents a
specific case of cluster scheduling (the Mesos-related classes
often subclass cluster scheduling classes). Thus, the most logical
place for it is within the cluster package.
Bug fix in master build
Merge pull request #930 from holdenk/master

Add mapPartitionsWithIndex
Merge pull request #670 from jey/ec2-ssh-improvements

EC2 SSH improvements
Merge pull request #14 from kayousterhout/untangle_scheduler

Improved organization of scheduling packages.

This commit does not change any code -- only file organization.
Please let me know if there was some masterminded strategy behind
the existing organization that I failed to understand!

There are two components of this change:
(1) Moving files out of the cluster package, and down
a level to the scheduling package. These files are all used by
the local scheduler in addition to the cluster scheduler(s), so
should not be in the cluster package. As a result of this change,
none of the files in the local package reference files in the
cluster package.

(2) Moving the mesos package to within the cluster package.
The mesos scheduling code is for a cluster, and represents a
specific case of cluster scheduling (the Mesos-related classes
often subclass cluster scheduling classes). Thus, the most logical
place for it seems to be within the cluster package.

The one thing about the scheduling code that seems a little funny to me
is the naming of the SchedulerBackends.  The StandaloneSchedulerBackend
is not just for Standalone mode, but instead is used by Mesos coarse grained
mode and Yarn, and the backend that *is* just for Standalone mode is instead called SparkDeploySchedulerBackend. I didn't change this because I wasn't sure if there
was a reason for this naming that I'm just not aware of.
Merge pull request #16 from pwendell/master

Bug fix in master build