mirror of https://github.com/apache/jclouds.git
474aa52da9
When the security group is not generated by jclouds (e.g. when using a custom group, or when in a VPC which generally requires its own security groups), the group name to launch nodes into is lost, since it is parsed from the generated security group ID. This patch introduces a very local workaround: try to parse the name from the key name, which if generated by jclouds has a format that is very similar to the generated security group ID. While probably not the ideal solution for persisting the group name either (using user metadata might be), this fixes a blocking issue for scenarios where you can't use a generated security group ID (using a VPC in our case), but you can use a generated key pair name. Also it shouldn't interfere with existing usage: if a name can be parsed from the security group, that is used, and if the key name is not generated, the behaviour remains as it currently is (group name is null if it can't be parsed from the security group). |
||
|---|---|---|
| .. | ||
| atmos | ||
| byon | ||
| cloudfiles | ||
| cloudloadbalancers | ||
| cloudservers | ||
| cloudsigma | ||
| cloudstack | ||
| cloudwatch | ||
| deltacloud | ||
| ec2 | ||
| elasticstack | ||
| eucalyptus | ||
| filesystem | ||
| nova | ||
| s3 | ||
| swift | ||
| vcloud | ||
| walrus | ||
| pom.xml | ||