Closed calebfornari closed 11 years ago
Instead of requiring the user to pass in security group ids for VPC I think we should look up the necessary id (and perhaps do it always so we don't need a separate code path just for VPC).
This is a little convoluted since boto does not allow fetching vpc security group by name, but I have modified to pull all security groups and then parse the list and match on name. This solves the dual code path problem and allows the user to always specify a security group name even when using a vpc subnet.
There actually is a way to do this in boto (at least in a new enough version), although it is somewhat hidden.
con.get_all_security_groups(groupnames=['default'])
That said, I think the current approach is a good place to start, we can optimize the boto call in a second pass.
That method works great as long as the named group is not in a VPC (I actually tried this first), if you try that with a VPC security group name however the aws response returns an explicit error stating that VPC security groups can only be retrieved by id. I am on boto 2.7, so it's possible that this changed in 2.8 but I doubt it since this seems to be a limitation of the aws api and not boto itself.
Ah, I should have checked this in VPC. Thanks again for getting this working :)
This appears to break in some cases when you have 2 security groups named the same thing. I think it needs to be modified to also take the instance and compare the instance type to find the right group. I'm investigating how to do this now.
I needed vpc support for a project I was working on so I went ahead and added it. Thought it might be useful to others.
Note that this change introduces parameter dependencies when using a vpc subnet in that security group identifiers must be passed as ID's instead of names, and at least one security group is required in order to create an instance in a vpc subnet. The documentation may need to be updated accordingly.