[pike] Allow to configure pool name for notifications
enable it by default with pool name 'barbican'.
This is follow-up to Id109c34b4ac0ae0250a28b570768ea64b074a173
in the release branch enabling this feature for Pike as well
Change-Id: I923e3c23cc3c5aeb95b29d8e93f6595a39b0b05b
Related-Issue: PROD-31028
diff --git a/README.rst b/README.rst
index 4e6800c..29d1578 100644
--- a/README.rst
+++ b/README.rst
@@ -157,7 +157,7 @@
it is preferable to leave this value as default and use
`ks_notifications_pool_name` (see below).
-`ks_notifications_pool_name` (Since Queens release) allows to use keystone
+`ks_notifications_pool_name` (Since Pike release) allows to use keystone
listener together with other applications listening on the same notifications
topic without interference between services.
Set it to any distinctive value to enable listener pooling.
diff --git a/barbican/files/pike/barbican.conf.Debian b/barbican/files/pike/barbican.conf.Debian
index ccebc39..a8882bc 100644
--- a/barbican/files/pike/barbican.conf.Debian
+++ b/barbican/files/pike/barbican.conf.Debian
@@ -296,6 +296,16 @@
# notifications.
topic = {{ server.get('ks_notifications_topic', 'notifications') }}
+# Pool name for notifications listener. Setting this to a distinctive
+# value will allow barbican notifications listener to receive its own
+# copy of all messages from the topic without without interfering with
+# other services listening on the same topic. This feature is
+# supported only by some oslo.messaging backends (in particilar by
+# rabbitmq) and for those it is preferrable to use it instead of
+# separate notification topic for barbican. (string value)
+#pool_name = <None>
+pool_name = {{ server.get('ks_notifications_pool_name', 'barbican') }}
+
# True enables requeue feature in case of notification processing error.
# Enable this only when underlying transport supports this feature.
allow_requeue = {{ server.get('ks_notifications_allow_requeue', 'False') }}