@andreaturli pushed 1 commit.
753638f fix listSecurityGroupsForNode
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/jclouds/jclouds/pull/1175/files/4e0b06b2510001ccd9a83f3166989d6119255f46..753638f986a376e6abd94ccc57ea35bad91a79af
I think creating a new virtualGuest is not a problem, but the problem is more
with the network/subnets. I believe with the new CDN accounts, virtualGuest
creations require subnetId as well, while I believe subnets need to live on
private networks, and there are limit number of private
[
https://issues.apache.org/jira/browse/JCLOUDS-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Turli reassigned JCLOUDS-1234:
-
Assignee: Andrea Turli
> openstack-nova - Indeterminate/invalid group reference
[
https://issues.apache.org/jira/browse/JCLOUDS-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrea Turli updated JCLOUDS-1234:
--
Fix Version/s: 2.1.0
> openstack-nova - Indeterminate/invalid group reference created in
nacx commented on this pull request.
> + return ImmutableSet.of();
+ }
+ return
getSecurityGroupApi(region).listSecurityGroups().concat().transform(neutronSecurityGroupToSecurityGroup.create(location)).toSet();
+ }
+
+ @Override
+ public Set
andreaturli commented on this pull request.
> + return ImmutableSet.of();
+ }
+ return
getSecurityGroupApi(region).listSecurityGroups().concat().transform(neutronSecurityGroupToSecurityGroup.create(location)).toSet();
+ }
+
+ @Override
+ public Set
andreaturli commented on this pull request.
> + return ImmutableSet.of();
+ }
+ return
getSecurityGroupApi(region).listSecurityGroups().concat().transform(neutronSecurityGroupToSecurityGroup.create(location)).toSet();
+ }
+
+ @Override
+ public Set
@nacx here's the result of `NeutronSecurityGroupExtensionLiveTest` against a
provider with keystone v3 and Neutron support
```
---
T E S T S
---
Running
nacx requested changes on this pull request.
I've debugged the failure and it turns to be a test concurrency issue with the
two tests that verify the behavior of the SG cache. If you apply this patch to
make sure both tests don't use the same security group, tests should pass:
```diff
diff