[
https://issues.apache.org/jira/browse/JCLOUDS-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842320#comment-13842320
]
Andrew Bayer commented on JCLOUDS-394:
--------------------------------------
At a minimum, I've created https://github.com/jclouds/jclouds/pull/221,
updating the README for apis/ec2 to explain that live tests won't work. I think
this is probably all we can do - the ec2 api still has to support the lowest
common denominator for a feature that's supported broadly across clouds
implementing the EC2 API, so we can't really change security group references
all to use groupId rather than groupName when OpenStack's EC2 shim still uses
groupId, etc...which, I guess, is the reason for the separate providers/aws-ec2
in the first place.
> EC2 Security Group logic won't work in non-default VPC
> ------------------------------------------------------
>
> Key: JCLOUDS-394
> URL: https://issues.apache.org/jira/browse/JCLOUDS-394
> Project: jclouds
> Issue Type: Bug
> Components: jclouds-compute
> Affects Versions: 1.6.3
> Reporter: Andrew Bayer
> Priority: Blocker
> Fix For: 1.7.0, 1.6.4
>
>
> Due to the change EC2 just made such that all new accounts are only in
> EC2-VPC for security groups, with their own default VPC set up for each
> account, all of our code that uses group *names* for parameters etc will fail
> for new accounts. This works (I'm pretty sure) from aws-ec2 where we're
> specifying groupId instead of groupName in a lot of places (hopefully all?),
> but I think we need to answer how to deal with this for the EC2 api proper as
> well.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
