Handle Invalid exceptions as expected in attach_interface
The bug prompting this is a tempest test which is requesting
a port attachment to a server but not specifying a port or
network to use, so nova-compute looks for a valid network
and finds there are two and raises NetworkAmbiguous. This
is treated as a 400 error in the API but because this is a
synchronous RPC call from nova-api to nova-compute,
oslo.messaging logs an exception traceback for the unexpected
error. That traceback is pretty gross in the compute logs for
something that is a user error and the cloud operator has
nothing to do to fix it.
We can handle the traceback by registering our expected
exceptions for the attach_interface method with oslo.messaging,
which is what this change does.
While looking to just add NetworkAmbiguous it became clear that
lots of different user errors can be raised from this method
and none of those should result in a traceback, so this change
just expects Invalid and its subclasses.
The one exception is InterfaceAttachFailed which is raised when
something in allocate_port_for_instance or driver.attach_interface
fails. That is an unexpected situation so the parent class for
InterfaceAttachFailed is changed from Invalid to NovaException so
it continues to be traced in the logs as an exception.
InterfaceAttachFailedNoNetwork is kept as Invalid since it is a
user error (trying to attach an interface when the user has no
access to any networks).
test_tagged_attach_interface_raises is adjusted to show the
ExpectedException handling for one of the Invalid cases.
Reviewed: https:/ /review. opendev. org/650077 /git.openstack. org/cgit/ openstack/ nova/commit/ ?id=ade6c939363 2e830c236882556 8769853fce3b99
Committed: https:/
Submitter: Zuul
Branch: master
commit ade6c9393632e83 0c2368825568769 853fce3b99
Author: Matt Riedemann <email address hidden>
Date: Thu Apr 4 13:04:33 2019 -0400
Handle Invalid exceptions as expected in attach_interface
The bug prompting this is a tempest test which is requesting
a port attachment to a server but not specifying a port or
network to use, so nova-compute looks for a valid network
and finds there are two and raises NetworkAmbiguous. This
is treated as a 400 error in the API but because this is a
synchronous RPC call from nova-api to nova-compute,
oslo.messaging logs an exception traceback for the unexpected
error. That traceback is pretty gross in the compute logs for
something that is a user error and the cloud operator has
nothing to do to fix it.
We can handle the traceback by registering our expected
exceptions for the attach_interface method with oslo.messaging,
which is what this change does.
While looking to just add NetworkAmbiguous it became clear that
lots of different user errors can be raised from this method
and none of those should result in a traceback, so this change
just expects Invalid and its subclasses.
The one exception is InterfaceAttach Failed which is raised when port_for_ instance or driver. attach_ interface tachFailed is changed from Invalid to NovaException so tachFailedNoNet work is kept as Invalid since it is a
something in allocate_
fails. That is an unexpected situation so the parent class for
InterfaceAt
it continues to be traced in the logs as an exception.
InterfaceAt
user error (trying to attach an interface when the user has no
access to any networks).
test_ tagged_ attach_ interface_ raises is adjusted to show the eption handling for one of the Invalid cases.
ExpectedExc
Change-Id: I927ff1d8c8f454 05833d6012b7d7a f37b98b10a0
Closes-Bug: #1823198