[
https://issues.apache.org/jira/browse/SPARK-3332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14116906#comment-14116906
]
Patrick Wendell commented on SPARK-3332:
----------------------------------------
I changed the title slightly - I think the underlying problem here is that
tagging is not atomic with launching instances. Removing the use of tagging
entirely is one potential solution for this. Another is that we just print
better errors if tagging does not succeed and explain there might be orphaned
instances.
The reason why SPARK-2333 was added is that the current approach can lead to
too many security groups, so we can't just revert this without any cost.
In the mean time I'd like to revert SPARK-2333 in branch-1.1 so we can defer
the design decision to the 1.2 release timeframe. Thanks [~douglaz] for
highlighting this issue.
> Tagging is not atomic with launching instances on EC2
> -----------------------------------------------------
>
> Key: SPARK-3332
> URL: https://issues.apache.org/jira/browse/SPARK-3332
> Project: Spark
> Issue Type: Bug
> Components: EC2
> Reporter: Allan Douglas R. de Oliveira
>
> The implementation for SPARK-2333 changed the machine membership mechanism
> from security groups to tags.
> This is a fundamentally flawed strategy as there aren't guarantees at all the
> machines will have a tag (even with a retry mechanism).
> For instance, if the script is killed after launching the instances but
> before setting the tags the machines will be "invisible" to a destroy
> command, leaving a unmanageable cluster behind.
> The initial proposal is to go back to the previous behavior for all cases but
> when the new flag (--security-group-prefix) is used.
> Also it's worthwhile to mention that SPARK-3180 introduced the
> --additional-security-group flag which is a reasonable solution to SPARK-2333
> (but isn't a full replacement to all use cases of --security-group-prefix).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
