VM launch fails with Neutron in "admin" tenant if "admin" and "demo" tenants have secgroups with a same name "web"

[Kevin Stevens]

Using Grizzly with Neutron: If there are multiple security groups with the same name (in other tenants for example), it is not possible to boot an instance with this security group as Horizon will only use the name of the security group.

Example from logs:
2013-07-21 03:39:12.432 ERROR nova.network.security_group.quantum_driver [req-aaca5681-72b8-41dc-a89c-9a5c95c7eff4 33fe423e114c4586a573514b3e98341e e91fe07ea4834f8487c5cec7deaa2eac] Quantum Error: Multiple security_group matches found for name 'web', use an ID to be more specific.
2013-07-21 03:39:12.439 ERROR nova.api.openstack [req-aaca5681-72b8-41dc-a89c-9a5c95c7eff4 33fe423e114c4586a573514b3e98341e e91fe07ea4834f8487c5cec7deaa2eac] Caught error: Multiple security_group matches found for name 'web', use an ID to be more specific.

[Marco Colombo (colo90)]

Hi Guys,
same problem here. Any news for the fix?

Thanks

[Julie Pichon (jpichon)]

If the fix isn't too invasive this should be fixed in RC1, the impact is serious and users shouldn't be blocked because they used the same security group name that someone else happens to be using in an unrelated project.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/46300

[Julie Pichon (jpichon)]

Note: This only happens if the user is an admin in the current project (this limits the impact a little).

[Akihiro Motoki (amotoki)]

[Havana] If we have the solutions in bug 1207184, this issue disappears from Havana.

[Grizzly]
Neturon security group support was added in Havana, so this issue still exists in Grizzly.
The proposed fix does not solve the issue since it break nova native security group implementation.

I am not sure it should be dealt with in Horizon not Nova itself.
When nova security group driver is "nova", we must pass "name".
When nova security group driver is "quantum", we must pass "uuid".
It is a strange API indeed.

[Minor correction] This happens in the following two cases.[
(1) the user has an admin role and security groups from all tenants are visible (as described in Julie's comment)
(2) a user creates multiple security groups in neutron by CLI. (very rase cases)

[Akihiro Motoki (amotoki)]

Sorry that my last comment is a bit wrong. Let me correct.
I was confused with add_security_group_instance and create_server.

The proposed fix looks insufficient with nova-network security group.

In Havana, the current behavior of Nova and Neutron are as follows:
(a1) nova-network security group (with nova driver) accepts "Name" of security groups.
(a2) Nova security group with neutron driver accepts UUID or Name.
(b) Neutron native security group API requires UUID.

In Grizzy, we need to consider cases (a1) and (a2).
(b2) does not need to be considered since Neutron native security group support is not implemented in Grizzly.

[Akihiro Motoki (amotoki)]

I think this issue should be fixed in nova ideally, but there seems to be several work around in Horizon.

Basically I think ID is better since it is unique in the system, so it looks good to me to change sg.name to sg.id as the proposed patch does. In addition to this, the possible workaround in Horizon are:

(1) Before/Inside calling server_create called from handle() in create_instance workflow class, if security_group ID is an integer (nova-network is used), to retrieve name according to its ID and pass security group name as a parameter of server_create()

(2) Similar to (1), to encode sg.id and sg.name with json in populate_groups_choices in project/instances/workflows/create_instance.py, and use sg.name when sg.id is an integer not UUID. This saves additional security_group_list API call.

(3) Use security_group name as security group ID if ID is an integer in api/nova. It can be done in api/nova SecurityGroup class.

All of the above options look workarounds to me, but it can help us.

I would like to know your opinions.

[Akihiro Motoki (amotoki)]

This is a bug of Nova.

We can reproduce it with CLI with "admin" user.
http://paste.openstack.org/show/47673/

The point is both "demo" and "admin" tenant have security groups named with "web".

[Akihiro Motoki (amotoki)]

In Horizon, there are two options:
(a) Add some workaround to avoid this bug,
(b) No fix in Havana and wait for Nova fix

[Gabriel Hurley (gabriel-hurley)]

As amotoki suggested, this is a fundamental incompatibility between Nova and Quantum's implementations (and personally I've thought Nova's use of the "name" instead of the "id" has been wrong for a long time). Given where we're at in the release cycle I don't want to add a lot of monkey-patching on our end to work around a bug that's not ours.

If Nova happens to fix this issue in their RC candidate, I'd love to fix it for us as well.

Otherwise, this should be included in the release notes for the Havana release.

[Akihiro Motoki (amotoki)]

The proposed patch in Horizon is insufficient and marked as "Do not Merge", so reset the status to "Confirmed".

[P. Watsalya Mishra (watsalya-mishra)]

So far I have found out that, when I am giving "nova secgroup-list" command, novaclient is sending "curl -i http://127.0.0.1:9696/v2.0/security-groups/8ae7b26b-8a28-4389-ad3b-0884e1aa5015.json" rest api to neutron that fetches tenant specific security group list.
On the other hand, when I am giving "nova boot" command from admin, with --security-groups flag set to certain security-group name which is already present in any other tenant, novaclient is sending "curl -i http://127.0.0.1:9696/v2.0/security-groups.json?fields=id&name=web -X GET -H "X-Auth-Token:" rest api to neutron that fetches all security groups irrespective of tenant.
I am moving forward in the direction of resolving below rest api to be generated as tenant-specific like one generated in case of giving "nova secgroup-list" command.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/131727

[OpenStack Infra (hudson-openstack)]

Change abandoned by Amandeep (<email address hidden>) on branch: master
Review: https://review.openstack.org/131727

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/211046

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/211046
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=5562694b7c81821820a846dd76471f66d8a47c12
Submitter: Jenkins
Branch: master

commit 5562694b7c81821820a846dd76471f66d8a47c12
Author: Radomir Dopieralski <email address hidden>
Date: Mon Aug 10 10:48:27 2015 +0200

    Use security group id not name in the create instance dialog

    It's possible to create multiple security groups with the same name,
    and then launching an instance will error with "Error: Multiple
    security_group matches found for name 'foo', use an ID to be more specific."

    The solution is to use the group id instead of group name in the form.

    This only works with Neutron, because Nova-Network not only requires the
    groups to be passed by name, but also passes them by name internally in
    several places.

    Change-Id: I83587e15a8c18d64a29fd1083e786a73162b19f9
    Partial-bug: #1203413

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/229767

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/229767
Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=5b9bdca15b31fbc75dc674da8d3f965ebe94cf1c
Submitter: Jenkins
Branch: stable/kilo

commit 5b9bdca15b31fbc75dc674da8d3f965ebe94cf1c
Author: Radomir Dopieralski <email address hidden>
Date: Mon Aug 10 10:48:27 2015 +0200

    Use security group id not name in the create instance dialog

    It's possible to create multiple security groups with the same name,
    and then launching an instance will error with "Error: Multiple
    security_group matches found for name 'foo', use an ID to be more specific."

    The solution is to use the group id instead of group name in the form.

    This only works with Neutron, because Nova-Network not only requires the
    groups to be passed by name, but also passes them by name internally in
    several places.

    Change-Id: I83587e15a8c18d64a29fd1083e786a73162b19f9
    Partial-bug: #1203413
    (cherry picked from commit 5562694b7c81821820a846dd76471f66d8a47c12)

[Sean Dague (sdague)]

This is legacy behavior in Nova network, and the kind of issue that isn't going to be addressed at this point.

[leegayeon (leegy)]

@Sean Dague
not legacy behavior in Nova network.
I hava same issue in neutron Havana.

[Ivan Kolodyazhny (e0ne)]

Looks like we've already merged patch to Horizon