addFloatingIP conflict is tracing in n-api logs

[Matt Riedemann]

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.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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)

[OpenStack Infra (hudson-openstack)]

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)

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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