]> git.apps.os.sepia.ceph.com Git - ceph.git/commitdiff
doc: update mgr modules notify_types 64531/head
authorNitzan Mordechai <nmordech@redhat.com>
Thu, 10 Jul 2025 10:03:06 +0000 (10:03 +0000)
committerZac Dover <zac.dover@proton.me>
Wed, 16 Jul 2025 11:56:30 +0000 (21:56 +1000)
Signed-off-by: Nitzan Mordechai <nmordec@redhat.com>
(cherry picked from commit fc4396d6280fcbf0a95567cff144052d81dcd964)

doc/mgr/modules.rst

index 4da8a2a9c0c462576a2c515df2d37f658a4e86d0..62a4f6a82f2103fdff330608b526f3d600dece49 100644 (file)
@@ -632,14 +632,31 @@ to the cluster.
 Receiving notifications
 -----------------------
 
-The manager daemon calls the ``notify`` function on all active modules
-when certain important pieces of cluster state are updated, such as the
-cluster maps.
-
-The actual data is not passed into this function, rather it is a cue for
-the module to go and read the relevant structure if it is interested.  Most
-modules ignore most types of notification: to ignore a notification
-simply return from this function without doing anything.
+The manager daemon can call the ``notify`` method on active modules
+when key pieces of cluster state are update such as the cluster maps.
+
+.. important::
+    Only modules that explicitly declare interest in a given
+    notification type will receive it.
+
+To receive notifications, a module must declare the NOTIFY_TYPES list:
+
+.. code:: python
+
+    NOTIFY_TYPES = [
+        NotifyType.mon_map,
+        NotifyType.osd_map,
+        NotifyType.crush_map,
+        ...
+    ]
+
+The manager will call the module ``notify`` method only for types listed
+in that array. Internally, it checks ``should_notify`` before dispatching
+the notification.
+
+The notification does not include the actual data - it's just a cue to
+tell the module that something has changed. It's up to the module to retrieve 
+fresh data using mgr.get(...) if needed.
 
 .. automethod:: MgrModule.notify