[
https://issues.apache.org/jira/browse/JCLOUDS-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854442#comment-15854442
]
Ignasi Barrera edited comment on JCLOUDS-1234 at 2/6/17 5:51 PM:
-----------------------------------------------------------------
As you mention, this is a limitation of the Nova API. Given how jclouds is
configured, different connections (and contexts) are configured for Nova and
Neutron, so the proposed fix was not possible before 2.0.0.
Starting from 2.0.0, we could use
[this|https://github.com/jclouds/jclouds/commit/613290ea8d16f3744cd25384a464b63594565495],
to inject an existing Neutron context into a Nova context. This way we could
make the Nova provider smarter and check if there is a Neutron instance there.
Depending on its presence we could use the Neutron security group api or
fallback tot he Nova one.
was (Author: nacx):
As you mention, this is a limitation of the Nova API. Given how jclouds is
configured, different connections (and contexts) are configured for Nova and
Neutron, so the proposed fix was not possible before 2.0.0.
Starting from 2.0.0, we could use
[this](https://github.com/jclouds/jclouds/commit/613290ea8d16f3744cd25384a464b63594565495),
to inject an existing Neutron context into a Nova context. This way we could
make the Nova provider smarter and check if there is a Neutron instance there.
Depending on its presence we could use the Neutron security group api or
fallback tot he Nova one.
> 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)
