Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "how to send notifications to the message bus by Nova". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Like other OpenStack services, Nova sends notifications to the message bus through the Notifier class provided by oslo.messaging. From the perspective of the notification consumer, the notification consists of two parts: the envelope of the fixed structure defined by oslo.messaging and the payload defined by the service that issued the notification. The format of envelope is as follows:

{"priority":, "event_type":, "timestamp":, "publisher_id":, "message_id":, "payload":}

There are two types of notifications in Nova: legacy notifications with non-version payloads and new notifications with version payloads.

Notification without version control

The Nova code uses nova.rpc.get 's notification call to get the configured oslo.messaging notification object, and then it uses the function provided by oslo on the Notifier object to issue the notification. The configuration of the returned Notifier object depends on the parameters of get notifier call and the values of the oslo.messaging configuration options driver and topics. There is a notification configuration option in Nova, which specifies a specific notification type, such as notifications.notify_on_state_change, notifications.default_level, etc.

The structure of the payload of an unversioned notifications is defined in the code that issues the notification, and there is no document in this format or a mandatory backward compatibility contract.

Notification of version control

The concept of version notification is created to correct the shortcomings of non-version notifications. The envelope structure that sends the notification is the same as the envelope structure in the unversioned notification case provided by oslo.messaging. However, the payload is not a random form dictionary, but a serialized oslo versionedobject.

For example, the wire format of service.update notification looks like this:

{"priority": "INFO", "payload": {"nova_object.namespace": "nova", "nova_object.name": "ServiceStatusPayload", "nova_object.version": "1.0", "nova_object.data": {"host": "host1", "disabled": false, "last_seen_up": null "binary": "nova-compute", "topic": "compute", "disabled_reason": null, "report_count": 1, "forced_down": false, "version": 2}, "event_type": "service.update", "publisher_id": "nova-compute:host1"}

The serialized oslo versionedobject provides the consumer with a version number as a payload so that the consumer can detect whether the structure of the load has changed. Nova provides the following contracts for the payload of versioned notifications:

If and only if the syntax or semantics of the nova object.data field of payload is changed, the payload version defined by the nova object.version field of payload will increase.

A small version of bump represents a backward compatible change, which means that only new fields are added to the payload, so a well-written consumer can still use the new payload without any changes.

A major version of bump indicates backward incompatible changes to the load, which may mean deleting fields, type changes, and so on in the payload.

In addition to 'nova_object.data' and' nova_object.version', there is an additional nova_object.name field on each payload.

One Nova configuration parameter is notifications.notification_format, which specifies what kind of notification can be sent by NOVA. Possible values are unversioned, versioned, or both. By default, both are fine.

The versioned notification is sent to a different topic than the legacy notifications. They are sent to versioned_notifications by default, but it can be modified by versioned_notifications_topic configuration options in the nova.conf file.

How to add versioned notifications

To support the above contract from Nova code, each version of the notification is modeled with oslo versionedobjects. Each version of the notification class should inherit nova.notifications.objects.base.NotificationBase, which has defined three mandatory fields for notifications, event_type, publisher_id, and priority. The new notification class should add a new field payload with an appropriate payload type. The load object of the notification should inherit the nova.objects.notifications.base.NotificationPayloadBase class and define the field of the payload as the versionedobject field. The next section describes the base class.

Nova.notifications.objects.base module

Note that notification objects should not be registered with NovaObjectRegistry to avoid mixing nova internal objects with notification objects. Use the register notification decorator on each specific notification object to replace it.

The following code example defines the necessary model classes for the new notification (myobject.update):

@ notification.notification_sample ('myobject-update.json') @ object_base.NovaObjectRegistry.register.register_notificationclass MyObjectNotification (notification.NotificationBase): # Version 1.0: Initial version VERSION =' 1.0' fields = {'payload': fields.ObjectField (' MyObjectUpdatePayload')} @ object_base.NovaObjectRegistry.register.register_notificationclass MyObjectUpdatePayload (notification.NotificationPayloadBase): # Version 1.0: Initial version VERSION = '1.0' fields = { 'some_data': fields.StringField () 'another_data': fields.StringField (),}

You can then use the following code to populate and send notifications:

Payload= MyObjectUpdatePayload (some_data= "foo", another_data= "bar") MyObjectNotification (publisher=notification.NotificationPublisher.from_service_obj (), event_type=notification.EventType (object='myobject', action=fields.NotificationAction.UPDATE), priority=fields.NotificationPriority.INFO, payload=payload) .emit (context)

The above code generates the following notification:

{"priority": "INFO", "payload": {"nova_object.namespace": "nova", "nova_object.name": "MyObjectUpdatePayload", "nova_object.version": "1.0"," nova_object.data ": {" some_data ":" foo "," another_data ":" bar ",}} "event_type": "myobject.update", "publisher_id": ":}

It is possible to reuse an existing versionedobject by adding a SCHEMA field to the payload class, which defines the mapping between the existing object field and the new payload object field. For example, service.status notifications reuse existing nova.objects.service.Service objects when defining the payload of a notification:

@ notification.notification_sample ('service-update.json') @ object_base.NovaObjectRegistry.register.register_notificationclass ServiceStatusNotification (notification.NotificationBase): # Version 1.0: Initial version VERSION =' 1.0' fields = {'payload': fields.ObjectField (' ServiceStatusPayload')} @ object_base.NovaObjectRegistry.register.register_notificationclass ServiceStatusPayload (notification.NotificationPayloadBase): SCHEMA = {'host': (' service', 'host') 'binary': ('service',' binary'), 'topic': (' service', 'topic'),' report_count': ('service',' report_count'), 'disabled': (' service', 'disabled'),' disabled_reason': ('service',' disabled_reason'), 'availability_zone': (' service', 'availability_zone') 'last_seen_up': (' service', 'last_seen_up'),' forced_down': ('service',' forced_down'), 'version': (' service', 'version')} # Version 1.0: Initial version VERSION =' 1.0' fields = {'host': fields.StringField (nullable=True),' binary': fields.StringField (nullable=True) 'topic': fields.StringField (nullable=True), 'report_count': fields.IntegerField (),' disabled': fields.BooleanField (), 'disabled_reason': fields.StringField (nullable=True),' availability_zone': fields.StringField (nullable=True), 'last_seen_up': fields.DateTimeField (nullable=True),' forced_down': fields.BooleanField (), 'version': fields.IntegerField () } def populate_schema (self, service): super (ServiceStatusPayload, self) .populate_schema (service=service)

If the SCHEMA field is defined, you need to populate the payload object by calling populate_schema before you start sending notifications:

Payload= ServiceStatusPayload () payload.populate_schema (service=) ServiceStatusNotification (publisher=notification.NotificationPublisher.from_service_obj (), event_type=notification.EventType (object='service', action=fields.NotificationAction.UPDATE), priority=fields.NotificationPriority.INFO, payload=payload) .emit (context)

The above code will generate data in JSON format online, similar to the above event_type for myobject.update format.

The data format of the SCHEMA field follows the following method:

(,)

The mapping defined in the SCHEMA field has the following semantics. When the populate_schema function is called, the contents of the SCHEMA field are enumerated and the field values pointing to the parameter object are copied into the requested payload field. Therefore, in the above example, the host field of the payload object is populated with the value of the host field of the service object, which is passed as a parameter to the populate_schema call.

Notified payload objects can reuse fields from multiple existing objects. Similarly, a notification can have both new and reused fields in its payload.

Note that there are two different ways to create a publisher instance of a notification. Created by a method that takes an instance of the NotificationPublisher object with host and binary string parameters, or through the NotificationPublisher.from_service_obj method to generate the Service object.

Versioned notifications has a sample file stored in the doc/sample_notifications directory and the notification object should be decorated with a notification_sample decorator. For example, service.update notifies that a sample file is stored in doc/sample_notifications/service-update.json and the ServiceUpdateNotification class is decorated accordingly.

The Notification payload class can use inheritance to avoid copying common payload fragments in nova code. However, you should create a leaf class directly for notification in the notification to avoid the need to add additional inheritance levels in the future, thus changing the name of the leaf class that appears in the payload class. If this cannot be avoided, the only change is renaming, then the version of the new payload should be the same as the old one before renaming.

This is the end of "how to send notifications to the message bus by Nova". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.