The 'nova.exception_wrapper.wrap_exception' decorator accepted either a
pre-configured notifier or a 'get_notifier' function, but the forget was
never provided and the latter was consistently a notifier created via a
call to 'nova.rpc.get_notifier'. Simplify things by passing the
arguments relied by 'get_notifier' into 'wrap_exception', allowing the
latter to create the former for us.
While doing this rework, it became obvious that 'get_notifier' accepted
a 'published_id' that is never provided nowadays, so that is dropped. In
addition, a number of calls to 'get_notifier' were passing in
'host=CONF.host', which duplicated the default value for this parameter
and is therefore unnecessary. Finally, the unit tests are split up by
file, as they should be.
Change-Id: I89e1c13e8a0df18594593b1e80c60d177e0d9c4c
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
The 'inspect.trace()' function is expected to be called within the
context of an exception handler. The 'from_exc_and_traceback' class
method of the 'nova.notification.objects.exception.ExceptionPayload'
class uses this to get information about a provided exception, however,
there are cases where this is called from outside of an exception
handler. In these cases, we see an 'IndexError' since we can't get the
last frame of a non-existent stacktrace. The solution to this is to
fallback to using the traceback embedded in the exception. This is a bit
lossy when decorators are involved but for all other cases this will
give us the same information. This also allows us to avoid passing a
traceback argument to the function since we have it to hand already.
Change-Id: I404ca316b1bf2a963106cd34e927934befbd9b12
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
Closes-Bug: #1881455
This patch adds full traceback to ExceptionPayload in versioned
notifications.
The instance fault field and instance-action REST API has already
provide the traceback to the admin users (controlable through policy)
and the notifications are also admin only things as they are emitted
to the message bus by default. So it is assumed that security is not
a bigger concern for the notification than for the REST API.
On the ML [1] post there was no objection to add new string field to the
ExceptionPayload that will hold the serialized traceback object.
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128105.html
Implements: blueprint add-full-traceback-to-error-notifications
Change-Id: Id587967ea4f9980c292492e2f659bf55fb037b28
In the nova notification code path the nova service / binary names
are hardcoded. There is a possible confusion as the REST API uses
'nova-osapi_compute' while the notifications use 'nova-api'
as the name of the nova compute service binary.
To make it clear that these names used in the notifications
are not the official service names the field storing it is renamed
from 'binary' to 'source'. This renaming means that the version of
NotificationPublisher ovo needed a major version bump. However this
does not effect the consumers of the notifications as the
NotificationPublisher is not directly serialized to the payload wire
format. Instead the value of the 'source' and 'host' fields are
dumped into the publisher_id field of the notification envelope.
Therefore this patch does not introduce a backward incompatible
change from the notification consumer perspective.
A subsequent patch will change this field to an enum to furter clarify
the possible values for notifications.
Change-Id: I95b5b0826190d396efe7bfc017f6081a6356da65
Related-Bug: #1696152
The **kwargs was used in the payload class ctor to pass the payload
fields initialization up to the ovo base class. This is unnecessary
and confusing.
This patch replaces the **kwargs passing with direct field initialization
to make the payload construction more explicit.
Change-Id: I7770f6550fa40c1d9b0417efa57f58fa9c998d45
Implements: bp versioned-notification-transformation-pike
Co-Authored-By: Stephen Finucane <sfinucan@redhat.com>
Wasting time on generating the payload of the notifications is
unnecessary if the notification will not be emitted due to
configuration.
This patch depends on an oslo messaging improvement that adds
a way to check if a Notifier will emit the notification or not.
Depends-On: Ib992f5c20fef85224fb00823e1d8d9c6cff19bec
Depends-On: I979fb3385671aba6f4162ef991da8f0febe0068a
Change-Id: I3e6741d59df49e1e58409314008c2ed609fdedc1
The wrap_exception decorator optionally emited a notification.
Based on the code comments the original intention was not to include the
context to that notification due to security reasons. However the
implementation did included the context to the payload of the legacy
notification.
Recently we saw circural reference errors during the payload serialization
of this notification. Based on the logs the only complex data structure
that could cause circural reference is the context. So this patch
removes the context from the legacy exception notification.
The versioned exception notification is not affected as it does not
contain the args of the decorated function.
Closes-Bug: #1673375
Change-Id: I1d217620e52d45595a3e0e49ed57b4ab33cd1688
1.As mentioned in [1], we should avoid using
six.iteritems to achieve iterators. We can
use dict.items instead, as it will return
iterators in PY3 as well. And dict.items/keys
will more readable. 2.In py2, the performance
about list should be negligible, see the link [2].
[1] https://wiki.openstack.org/wiki/Python3
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html
The patch list:
1. cells.
2. compute api.
3. image.
4. network.
5. objects.
6. scheduler.
7. virt.
8. other resources.
Partial-Implements: blueprint replace-iteritems-with-items
Change-Id: Ic6e469eb80ee1774de1374bb36f38b5134b6b311
A new versioned notification is emitted from the wrap_exception
decorator.
Change-Id: I8fcbce111537dae6ad3ba0961fb761540ae800ed
Partially-Implements: bp versioned-notification-transformation-newton