[ 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 created in ingress > rule if duplicate groups in region > ------------------------------------------------------------------------------------------------------------ > > Key: JCLOUDS-1234 > URL: https://issues.apache.org/jira/browse/JCLOUDS-1234 > Project: jclouds > Issue Type: Bug > Components: jclouds-compute > Affects Versions: 2.0.0 > Reporter: Geoff Macartney > Assignee: Andrea Turli > Priority: Major > Labels: openstack-neutron, openstack-nova > Fix For: 2.1.0 > > > When converting a Nova security group to its jclouds representation, the > class {{FindSecurityGroupWithNameAndReturnTrue}} is used to find a security > group in the list of groups in a location by matching on name with a “query > object”: > https://github.com/apache/jclouds/blob/rel/jclouds-2.0.0/apis/openstack-nova/src/main/java/org/jclouds/openstack/nova/v2_0/predicates/FindSecurityGroupWithNameAndReturnTrue.java#L66-L73 > {code} > SecurityGroup returnVal = Iterables.find(api.get().list(), new > Predicate<SecurityGroup>() { > @Override > public boolean apply(SecurityGroup input) { > return input.getName().equals(securityGroupInRegion.getName()); > } > }); > {code} > However, it is possible for there to be duplicate group names among the > security groups in a location. Say we have a location with two groups, G1 and > G2, both with name “foobar”. In such a case, if a security group G3 has > ingress rules permitting access from “foobar”, then it is not possible with > the Nova {{/v2/12345/os-security-groups}} API to know which group is > intended, as the only information it returns about referred groups is the > tenant id and name: > {code} > "group": { > "tenant_id": "12345abcde12345abcde12345abcde", > "name": "foobar" > }, > {code} > With this definition of the API the ingress rule is ambiguous. The code for > {{FindSecurityGroupWithNameAndReturnTrue}} above implicitly assumes that > group names are distinct, and so it will arbitrarily assign the security > access to whichever of G1 and G2 it encounters first in the {{find}}, > possibly the wrong group, thus mapping the rule incorrectly. > The fix for this is probably to switch to using the v3 security groups API in > Neutron, which returns the actual security group id in the definitions of > ingress rules and not just the name. -- This message was sent by Atlassian JIRA (v7.6.3#76005)