[jira] [Assigned] (JCLOUDS-1234) openstack-nova - Indeterminate/invalid group reference created in ingress rule if duplicate groups in region

["Andrea Turli (JIRA)" <ji...@apache.org>]

     [ 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)