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.
Change-Id: I927ff1d8c8f45405833d6012b7d7af37b98b10a0
Closes-Bug: #1823198
(cherry picked from commit ade6c93936)
e9261764c9