On Tue, Mar 7, 2017 at 8:42 PM, Matt Riedemann <mriede...@gmail.com>
wrote:
While digging through nova code today to compare versioned and
unversioned notifications, and reading specs and seeing how
seachlight handles nova notifications, I noticed that the unversioned
notifications have a "compute." prefix in the name. The versioned
notifications do not.
It also took me awhile but I also sorted out that unversioned
notifications are on the 'notifications' topic which is the default
in oslo.messaging ([oslo_messaging_notifications]topics) and
versioned notifications are on the 'versioned_notifications' topic.
Yes, versioned notifications are always emitted to the
'versioned_notifications' topic. Sorry if that wasn't clear from the
notification dev-ref. The actual code is here [5]
My question is, was it intentional to drop the "compute." prefix from
the event type on the versioned notifications? I didn't see anything
specifically stating that in the original spec [1].
Quote from the spec [1]:
The value of the event_type field of the envelope on the wire will be
defined by the name of the affected object, the name of the performed
action emitting the notification and the phase of the action. For
example: instance.create.end, aggregate.removehost.start,
filterscheduler.select_destinations.end. The notification model will do
basic validation on the content of the event_type e.g. enum for valid
phases will be created.
So yes, dropping the compute prefix was intentional as the information
carried by the prefix was already in the publisher_id of the
notification.
The goal was that the publisher_id should define what service emitted
the notifications and the event_type should be a unique id of the given
event regardless of which service emits that event. For example the
event_type instance.delete.start is used by nova-compute and
nova-conductor service. The publisher_id will contain the name of the
service binary and the hostname where that binary runs[3][4]
[3]
https://review.openstack.org/#/c/410297/12/doc/notification_samples/instance-delete-start_not_scheduled.json@59[4]
https://github.com/openstack/nova/blob/master/doc/notification_samples/instance-delete-start.json#L72
[5] https://github.com/openstack/nova/blob/master/nova/rpc.py#L92-L99
Since the notifications are on independent topics it probably doesn't
matter. I was just thinking about this from the searchlight
perspective because they don't support nova versioned notifications
yet and already have code to map the "compute." event types [2], I
wasn't sure if they could re-use that and just listen on the
'versioned_notifications' topic. In talking with Steve McLellan it
doesn't sound like the different event types format will be an issue.
Honestly, If searchlight needs to be adapted to the versioned
notifications then the smallest thing to change is to handle the
removed prefix from the event_type. The biggest difference is the
format and the content of the payload. In the legacy notifications the
payload was a simply json dict in the versioned notification the
payload is a json serialized ovo. Which means quite a different data
structure. E.g. extra keys, deeper nesting, etc.
Cheers,
gibi
[1]
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/versioned-notification-api.html
[2]
https://github.com/openstack/searchlight/blob/2.0.0/searchlight/elasticsearch/plugins/nova/notification_handler.py#L82
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
