Open Stack

On Tue, Mar 7, 2017 at 8:42 PM, Matt Riedemann <mriedemos at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev