Uploaded image for project: 'jclouds'
  1. jclouds
  2. JCLOUDS-1234

openstack-nova - Indeterminate/invalid group reference created in ingress rule if duplicate groups in region

    XMLWordPrintableJSON

    Details

      Description

      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

              SecurityGroup returnVal = Iterables.find(api.get().list(), new Predicate<SecurityGroup>() {
      
                  @Override
                  public boolean apply(SecurityGroup input) {
                     return input.getName().equals(securityGroupInRegion.getName());
                  }
      
               });
      

      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:

                              "group": {
                                 "tenant_id": "12345abcde12345abcde12345abcde",
                                 "name": "foobar"
                              },
      

      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.

        Attachments

          Activity

            People

            • Assignee:
              andreaturli Andrea Turli
              Reporter:
              geomacy Geoff Macartney
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: