create_with_nonexistent_security_group fails : Quantum returns a 404 where Nova-network returns a 400

Bug #1183347 reported by Jordan Pittier
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Undecided
melanie witt
tempest
Fix Released
Medium
Unassigned

Bug Description

In test_servers_negative::test_create_with_nonexistent_security_group a exceptions.BadRequest 400 is expected. But with Quantum, a 404 Not found is thrown instead. Thus the test fails.

See https://github.com/openstack/nova/blob/master/nova/network/security_group/quantum_driver.py#L97

Sean Dague (sdague)
Changed in tempest:
importance: Undecided → Medium
status: New → Confirmed
milestone: none → havana-1
Changed in nova:
status: New → Confirmed
melanie witt (melwitt)
Changed in nova:
assignee: nobody → Melanie Witt (melwitt)
status: Confirmed → In Progress
Revision history for this message
melanie witt (melwitt) wrote :

Quantum driver is raising exc.HTTPNotFound exception from nova/api/openstack/compute/contrib/security_groups.py NativeSecurityGroupExceptions, which gives the 404.

In nova/api/openstack/compute/servers.py, exception.SecurityGroupNotFound (that's raised at the nova db layer) is caught and then exc.HTTPBadRequest raised, so nova-network gives the 400 result.

There's a kwarg, map_exception, for the SecurityGroupAPI::get function in nova/compute/api.py that defaults to False. Because it's False, it re-raises the exception.SecurityGroupNotFound instead of mapping it to exc.HTTPNotFound.

There are different ways to handle this:

1. Raise exc.HTTPNotFound in nova/api/openstack/compute/servers.py when exception.SecurityGroupNotFound is caught

2. Call SecurityGroupAPI::get with map_exception=True

3. Have quantum driver raise exception.SecurityGroupNotFound instead of exc.HTTPNotFound if quantum api responds with 404.

Revision history for this message
Sean Dague (sdague) wrote :

I think option 3 is more in line with what we do on other drivers.

Revision history for this message
melanie witt (melwitt) wrote :

Thanks, appreciate the guidance.

I went to do option 3 but the security group api (both nova and quantum) has semantics to map not found to not found. If you were to make a rest call to SecurityGroupAPI::get, the response should be a 404.

This situation is different since we're trying to create a server and fetching the security group fails because it wasn't found and we want to respond with bad request. It's not the same as the straightforward "not found" of a standalone security group api call as the create server request was invalid overall.

The SecurityGroupAPI::get function is throwing, not add_to_instance. Get is called as part of _check_requested_secgroups in the compute api as part of the validation that happens for a create server request.

I'm thinking of raising exception.SecurityGroupNotFound in _check_requested_secgroups instead of in quantum driver in order to leave the SecurityGroupAPI semantics intact. I think we only want to have a bad request response if the security group isn't found during a server create.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

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

Sean Dague (sdague)
Changed in tempest:
milestone: havana-1 → havana-2
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to tempest (master)

Reviewed: https://review.openstack.org/30271
Committed: http://github.com/openstack/tempest/commit/2c2978703319631f1c0144db05f55dbad3a55c50
Submitter: Jenkins
Branch: master

commit 2c2978703319631f1c0144db05f55dbad3a55c50
Author: JordanP <email address hidden>
Date: Thu May 23 15:34:16 2013 +0200

    Update a test to work with Quantum SecGroup

    Nova-Network and Quantum return different error code to an
    non existent security group

    Fix Bug #1183347

    Change-Id: Iae2d86938b5c3df0af99e760ac7933bcdd8f9007

Changed in tempest:
status: Confirmed → Fix Released
Revision history for this message
melanie witt (melwitt) wrote :

I'm gathering opinions from nova reviewers on whether to refactor the security group api not to raise http-level exceptions as part of fixing this correctly on the nova side.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

Reviewed: https://review.openstack.org/30815
Committed: http://github.com/openstack/nova/commit/3401cca5bbc89f713d5c853f62a713d6219dac28
Submitter: Jenkins
Branch: master

commit 3401cca5bbc89f713d5c853f62a713d6219dac28
Author: Melanie Witt <email address hidden>
Date: Wed May 29 01:01:07 2013 +0000

    refactor security group api not to raise http exceptions

    The SecurityGroupAPI had been raising http exceptions,
    resulting in a difference in behavior depending on the
    driver being used: nova or quantum. The nova driver
    re-raises nova exceptions by default, while the quantum
    driver was raising the built-in http exceptions. Since
    servers.py handles nova exceptions, in some cases the
    quantum driver's http exceptions weren't being handled
    and resulted in a different http return code to the
    user.

    Both SecurityGroupAPI classes inherit from
    NativeSecurityGroupExceptions and call its static
    methods to raise exceptions.

    This change refactors SecurityGroupAPI to raise nova
    exceptions by modifying NativeSecurityGroupExceptions.
    The nova exceptions are then translated to http
    exceptions in the security group wsgi extension.

    Fixes bug 1183347

    Change-Id: I7177183154b4c41037623f443cf9958ac457a020

Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in nova:
milestone: none → havana-2
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: havana-2 → 2013.2
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.