[ 
https://issues.apache.org/jira/browse/SPARK-3398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14187593#comment-14187593
 ] 

Nicholas Chammas commented on SPARK-3398:
-----------------------------------------

OK, so you're invoking {{spark-ec2}} from an Ubuntu server. I wonder if that 
matters any, specifically when we make [this 
call|https://github.com/apache/spark/blob/4b55482abf899c27da3d55401ad26b4e9247b327/ec2/spark_ec2.py#L615].

What happens if you replace the code at that line with this version?

{code}
ret = subprocess.check_call(
                ssh_command(opts) + ['-t', '-t', '-o', 'ConnectTimeout=3',
                                     '%s@%s' % (opts.user, host), 
stringify_command('true')]
            )
{code}

This will just print SSH's output to the screen instead of suppressing it. If 
anything's going wrong, it should be more obvious that way.

> Have spark-ec2 intelligently wait for specific cluster states
> -------------------------------------------------------------
>
>                 Key: SPARK-3398
>                 URL: https://issues.apache.org/jira/browse/SPARK-3398
>             Project: Spark
>          Issue Type: Improvement
>          Components: EC2
>            Reporter: Nicholas Chammas
>            Assignee: Nicholas Chammas
>            Priority: Minor
>             Fix For: 1.2.0
>
>
> {{spark-ec2}} currently has retry logic for when it tries to install stuff on 
> a cluster and for when it tries to destroy security groups. 
> It would be better to have some logic that allows {{spark-ec2}} to explicitly 
> wait for when all the nodes in a cluster it is working on have reached a 
> specific state.
> Examples:
> * Wait for all nodes to be up
> * Wait for all nodes to be up and accepting SSH connections (then start 
> installing stuff)
> * Wait for all nodes to be down
> * Wait for all nodes to be terminated (then delete the security groups)
> Having a function in the {{spark_ec2.py}} script that blocks until the 
> desired cluster state is reached would reduce the need for various retry 
> logic. It would probably also eliminate the need for the {{--wait}} parameter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to