addFloatingIP conflict is tracing in n-api logs

Bug #1693576 reported by Matt Riedemann
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Medium
Matt Riedemann
Newton
Fix Committed
Medium
Matt Riedemann
Ocata
Fix Committed
Medium
Matt Riedemann

Bug Description

This Tempest negative test was added back in March:

https://github.com/openstack/tempest/commit/343ca198166ded0bbf6e23535aeae0ea15a922dc

It passes but it results in an ugly stacktrace in the n-api logs:

http://logs.openstack.org/89/466889/2/gate/gate-tempest-dsvm-neutron-full-ubuntu-xenial/57732b0/logs/screen-n-api.txt.gz?level=TRACE#_May_24_07_30_30_975142

Which is normally a place where we shouldn't stacktrace if it's not a 500 error.

This is an expected situation, and we should be able to handle the 409 Conflict from Neutron and translate that to a proper error handled at the top REST API controller.

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/468136

Changed in nova:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (stable/ocata)

Fix proposed to branch: stable/ocata
Review: https://review.openstack.org/469671

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

Fix proposed to branch: stable/newton
Review: https://review.openstack.org/469672

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

Reviewed: https://review.openstack.org/468136
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=452f21183f2f80cc5673ebd3fd3e5daf039caacc
Submitter: Jenkins
Branch: master

commit 452f21183f2f80cc5673ebd3fd3e5daf039caacc
Author: Matt Riedemann <email address hidden>
Date: Thu May 25 15:00:24 2017 -0400

    Handle conflict from neutron when addFloatingIP fails

    Neutron can raise a Conflict exception when attempting
    to associate a floating IP to a server when the fixed
    address is already associated to another floating IP.
    This has always resulted in a 400 response, however, it
    would also trace an ERROR in the nova-api logs, which is
    something we shouldn't be doing for an expected type of
    failure.

    This handles the Conflict in the neutronv2 API client code
    and re-raises an exception that the REST API controller code
    can handle and return as a 400 without the stacktrace in the
    logs.

    Change-Id: I27d3241300f75e2aa79a32348a3843e09123cb10
    Closes-Bug: #1693576

Changed in nova:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 16.0.0.0b2

This issue was fixed in the openstack/nova 16.0.0.0b2 development milestone.

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

Reviewed: https://review.openstack.org/469671
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=55684f6ac43ce2c55829337b7d24fe3059b866a8
Submitter: Jenkins
Branch: stable/ocata

commit 55684f6ac43ce2c55829337b7d24fe3059b866a8
Author: Matt Riedemann <email address hidden>
Date: Thu May 25 15:00:24 2017 -0400

    Handle conflict from neutron when addFloatingIP fails

    Neutron can raise a Conflict exception when attempting
    to associate a floating IP to a server when the fixed
    address is already associated to another floating IP.
    This has always resulted in a 400 response, however, it
    would also trace an ERROR in the nova-api logs, which is
    something we shouldn't be doing for an expected type of
    failure.

    This handles the Conflict in the neutronv2 API client code
    and re-raises an exception that the REST API controller code
    can handle and return as a 400 without the stacktrace in the
    logs.

    Change-Id: I27d3241300f75e2aa79a32348a3843e09123cb10
    Closes-Bug: #1693576
    (cherry picked from commit 452f21183f2f80cc5673ebd3fd3e5daf039caacc)

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

Reviewed: https://review.openstack.org/469672
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=76d59ebcb9ace58d9364877da25f1aa66fb759d8
Submitter: Jenkins
Branch: stable/newton

commit 76d59ebcb9ace58d9364877da25f1aa66fb759d8
Author: Matt Riedemann <email address hidden>
Date: Thu May 25 15:00:24 2017 -0400

    Handle conflict from neutron when addFloatingIP fails

    Neutron can raise a Conflict exception when attempting
    to associate a floating IP to a server when the fixed
    address is already associated to another floating IP.
    This has always resulted in a 400 response, however, it
    would also trace an ERROR in the nova-api logs, which is
    something we shouldn't be doing for an expected type of
    failure.

    This handles the Conflict in the neutronv2 API client code
    and re-raises an exception that the REST API controller code
    can handle and return as a 400 without the stacktrace in the
    logs.

    Conflicts:
          nova/tests/unit/network/test_neutronv2.py

    NOTE(mriedem): The conflict is due to not having change
    I740c49111bc8e5e76a2fe42b35e8d6c9267e04a2 in Newton.

    Change-Id: I27d3241300f75e2aa79a32348a3843e09123cb10
    Closes-Bug: #1693576
    (cherry picked from commit 452f21183f2f80cc5673ebd3fd3e5daf039caacc)
    (cherry picked from commit cea9f71634a161dc58a0c9a43d44a6e9d12ddc4c)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 15.0.7

This issue was fixed in the openstack/nova 15.0.7 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/nova 14.0.8

This issue was fixed in the openstack/nova 14.0.8 release.

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.