Hi all, Apologies for re-opening an old thread but we've just hit a problem with this root cause.
I'm not aware of any reason why security groups and VPCs should be mutually exclusive, as the jclouds docs state. VPC instances certainly *can* have security groups attached, although there is a difference in that security groups have to be specified by ID rather than name when creating the instance. If we are using the "inboundPorts" feature of template options to get jclouds to create the security group for us, that should still work regardless of whether we're using VPCs or not. However it does not; as soon as a subnet ID is given, jclouds seems to not attempt to create a security group for inbound ports, nor attach the security group to the new instance. Does this have to be the case? How difficult a task is this to change in jclouds? Thanks, Richard. On 17 November 2014 at 21:48, Andrew Phillips <[email protected]> wrote: > Hi Yaron > >>> "To create nodes in a subnet under Amazon VPC add the following option to >>> your template options. Note that VPCs and Security Groups are mutually >>> exclusive." >>> >>> Why? > > > From what I understand, "Security Groups" here refers to the "classic" > security groups that are referred to as "EC2-Classic" in the AWS docs. These > state, for example: > > "You can't specify a security group that you created for a VPC when you > launch an instance in EC2-Classic." and "You can't specify a security group > that you created for EC2-Classic when you launch an instance in a VPC." [1] > > You should be able to specify the security groups *in your VPC* by using the > securityGroupIds template builder option on AWSEC2TemplateOptions [2] > (rather than the securityGroups option which, if I recall correctly, selects > the old-style groups). > > See also this thread [3]. > > Regards > > ap > > [1] > http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html > [2] > http://javadocs.jclouds.cloudbees.net/org/jclouds/aws/ec2/compute/AWSEC2TemplateOptions.Builder.html > [3] http://apache.markmail.org/thread/7ssdg7ww4c652gyj
