jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ignasi Barrera (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (JCLOUDS-1234) openstack-nova - Indeterminate/invalid group reference created in ingress rule if duplicate groups in region
Date Tue, 06 Feb 2018 09:48:00 GMT

     [ https://issues.apache.org/jira/browse/JCLOUDS-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Ignasi Barrera updated JCLOUDS-1234:
    Fix Version/s:     (was: 2.1.0)

> 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
> 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
> {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

View raw message