[
https://issues.apache.org/jira/browse/WHIRR-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13189151#comment-13189151
]
Evan Pollan commented on WHIRR-482:
-----------------------------------
Andrei,
I have an application that spins up an cluster with a well-defined name.
During some testing, several instances of that application were deployed to
different servers, each creating their own clusters using the same set of EC2
credentials. I can understand the motivation behind ensuring that
bootstrap-failure orphans are cleaned up, but it would seem safer to combine
the cluster name with some type of unique token generated by whirr when hunting
down orphans.
Evan
> destroy-cluster in EC2 terminates any instance belonging to the cluster's
> security group, even if it's not a member of the cluster
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WHIRR-482
> URL: https://issues.apache.org/jira/browse/WHIRR-482
> Project: Whirr
> Issue Type: Bug
> Affects Versions: 0.6.0
> Reporter: Evan Pollan
>
> I had three different whirr-created clusters running in EC2, 2 of which
> shared the same cluster name (and, thus, the same security group). They were
> all created from different machines -- i.e. the ~/.whirr/<cluster>/instances
> files were all on different instances. I invoked destroy-cluster from one of
> the "initiating" machines that had created one of the two identically named
> clusters, and the destruction process terminated all of the instances in the
> cluster "owned" by the machine running the destroy-cluster command, as well
> as all of the instances of the other cluster sharing that name.
> Since whirr writes an inventory of all the instances it creates to
> ~/.whirr/<cluster>/instances, shouldn't it use that manifest to drive it's
> instance termination behavior?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
