From f8c3eb9d4cd9ed02dce44d3700170fdc5a7c2e91 Mon Sep 17 00:00:00 2001 From: dineshbhor Date: Thu, 31 Oct 2019 13:40:51 +0900 Subject: [PATCH] Support notification Transports per oslo messaging notifications Add spec related to the blueprint: https://blueprints.launchpad.net/oslo.messaging/+spec/support-transports-per-oslo-notifications Change-Id: I8c9cba473c61c677bdec4bc5f5e0a43635379f71 Partial-Implements: blueprint support-transports-per-oslo-notifications --- ...port-transports-per-oslo-notifications.rst | 219 ++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 specs/ussuri/support-transports-per-oslo-notifications.rst diff --git a/specs/ussuri/support-transports-per-oslo-notifications.rst b/specs/ussuri/support-transports-per-oslo-notifications.rst new file mode 100644 index 0000000..8d41363 --- /dev/null +++ b/specs/ussuri/support-transports-per-oslo-notifications.rst @@ -0,0 +1,219 @@ +================================================================= + Support notification Transports per oslo messaging notifications +================================================================= + +https://blueprints.launchpad.net/oslo.messaging/+spec/support-transports-per-oslo-notifications + +Large clouds where the cloud is being maintained with multiple regions, +operators usually configure global components(for ex: Designate, Ceilometer) +in the DR(Disaster Recovery) fashion. The core services like Nova and +Neutron are then configured to send oslo.messaging notifications to both +the region based components(for ex: Searchlight) and at the same time to +global components. Currently oslo.messaging only allows to send all the +notifications to just one underlying messaging transport(for ex: +one rabbitmq cluster which has deployed region based components). +This spec proposes to add feature into oslo.messaging which enables operators +to define different transport_url for each notification so that they can be +sent to the different messaging transport(for ex: rabbitmq clusters) + +Problem description +=================== + +``oslo.messaging`` allows to specify the drivers and notifications transports +in each components config files like below For example, in nova. + +.. code-block:: ini + + [oslo_messaging_notifications] + driver = messaging + topics = notifications,notifications_designate + transport_url = rabbit://username:password@rabbit001.com:5672 + + +With above configuration the ``notifications`` and ``notifications_designate`` +related notifications are sent to the defined ``transport_url`` to +``rabbit001.com``. If the designate service is deployed onto different +region/cluster which is using different rabbitmq cluster, currently there is no +way to send only the ``notifications_designate`` to say ``rabbit002.com`` which +is designate service rabbitmq cluster. + +Operators should be allowed to send the notifications into different underlying +messaging transport based on the ``transport_url per notification``. + + +Proposed change +=============== + +The spec proposes to follow the same implementation of ``enabled_backends`` +done Cinder [1]_ and Glance [2]_ components. + +Define dynamic new config group for each notification +----------------------------------------------------- + +For example: + +.. code-block:: ini + + [oslo_messaging_notifications] + driver = messaging + topics = notifications,notifications_designate,any_other_notification + transport_url = rabbit://username:password@rabbit001.com:5672 + + [notifications] + transport_url = rabbit://username:password@rabbit001.com:5672 + + [notifications_designate] + transport_url = rabbit://username:password@rabbit002.com:5672 + +As described in the above config section, ``[oslo_messaging_notifications]`` +section contains the list of ``topics`` being used for notifications. +Each of the notification is then dynamically grouped later and has its own +``transport_url``. + +By default if the transport_url is not defined for any of the notification +it will fall back to the main sections transport_url +``[oslo_messaging_notifications]`` and if it is defined over there as well then +it will finally fallback to the transport_url defined in the +``[oslo_messaging_rabbit]``. +In the above example ``notifications`` topic uses ``rabbit001.com`` rabbitmq +cluster. ``notifications_designate`` uses ``rabbit002.com`` rabbitmq cluster +and ``any_other_notification`` used ``rabbit002.com`` rabbitmq cluster. + +The notifications will inherit all the other config option values like +``driver`` etc. + +This change is backward compatible so even if operator do not specify each +notifications transport_urls they will fall back to the main sections. + +This change does not require any changes to oslo.config since everything is +already supported. + +Also this will not require the clients like Nova, Neutron to change their +config files. + + +Alternatives +------------ + +This use case can be implemented with below new feature: + +#. Add ``MultiOptGroup`` support in oslo.conf same as ``MultiOpt``. +#. Make use of ``MultiOptGroup`` in oslo.messaging and in the clients like + Nova and Neutron + +For example: + +.. code-block:: ini + + [oslo_messaging_notifications] + driver = messaging + topics = notifications + transport_url = rabbit://username:password@rabbit001.com:5672 + + [oslo_messaging_notifications] + driver = messaging + topics = notifications_designate + transport_url = rabbit://username:password@rabbit002.com:5672 + + [oslo_messaging_notifications] + driver = messaging + topics = any_other_notification + transport_url = rabbit://username:password@rabbit001.com:5672 + +This solution requires to add a new feature in oslo.config which will allow to +define the option group multiple times as shown above which can be used in +oslo.messaging to define the transport_urls per notification. +This feature might be useful in other use-cases as well where it is required +to define the group multiple times. + +One more alternative could be to use RabbitMQ Shovel plugin (in case if you are +using rabbitmq as a messaging backend) to move messages from one cluster to +other cluster. Shovel plugin also has limitations and RabbitMQ community does +not allow to use multiple ``dest-uri`` in the shovel policy so that means you +can not send the notifications to two different clusters at the same time in +one policy. Offcourse you can define more than one policy per notification. +The other disadvantage of this approach is RabbitMQ shovel plugin actually +creates a non-existent queue on the RabbitMQ node as a durable queues because +thats the behaviour of Shovel plugin and if the OpenStack service is not using +durable queues the service will fail to send the messages to rabbitmq and gives +below error: +Error: Queue.declare: (406) PRECONDITION_FAILED + +Impact on Existing APIs +----------------------- + +No impact. + +Security impact +--------------- + +No impact. + +Performance Impact +------------------ + +No impact. + +Configuration Impact +-------------------- + +Each notification will have its own group which can be defined like above. + +Developer Impact +---------------- + +No impact. + +Testing Impact +-------------- + +Additional unit tests will be required to cover the added functionality. + +Implementation +============== + +Assignee(s) +----------- + +Primary assignee: + Dinesh_Bhor (bhordinesh07@gmail.com) + +Other contributors: + volunteers? + +Milestones +---------- + +..TODO(Dinesh_Bhor): figure this out + +Work Items +---------- + +* Implement the new dynamic ``notifications`` OptGroup generation. +* Integrate it in `get_notifications_transport` and ``Notifier`` class. +* Update documentation. +* Update the sample configuration generator to include the variable names. +* Update the documentation generator to include the variable names. + + +Incubation +========== + +N/A + +Documentation Impact +==================== + +The documentation will need to be updated to indicate that notification option +can be overridden with its own dedicated group. + +Dependencies +============ + +N/A + +References +========== + +.. [1] https://github.com/openstack/glance/blob/0bb0fca24c23d8e8000ce7a3cabc695aec52f334/doc/source/admin/multistores.rst +.. [2] https://github.com/openstack/cinder/blob/ea04cda682168b642ae2fa823338c4dd26e5c86c/doc/source/admin/blockstorage-multi-backend.rst