[
https://issues.apache.org/jira/browse/JCLOUDS-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignasi Barrera updated JCLOUDS-1234:
------------------------------------
Labels: openstack-neutron openstack-nova (was: )
> 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
> Labels: openstack-neutron, openstack-nova
>
> 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
(v6.3.15#6346)
