Issue 3211 - Integrate customservice::supervisor with notification daemon

hiera/roles/filterserver.yaml

Index: hiera/roles/filterserver.yaml
diff --git a/hiera/roles/filterserver.yaml b/hiera/roles/filterserver.yaml
index ca04f95164a5ca8d1aee2160f24e269a91518199..cba14aa85a086e020d44cc671dbb3479737865eb 100644
--- a/hiera/roles/filterserver.yaml
+++ b/hiera/roles/filterserver.yaml
@@ -4,4 +4,8 @@ classes:
     is_default: true
   notificationserver:
     is_default: false
+  sitescripts::keep_alive_services:
+
+sitescripts::keep_alive_service_pidfiles:
+  spawn-fcgi: /var/run/500-multiplexer_spawn-fcgi.pid

[Wladimir Palant, 2015/10/21 11:05:26]

The script expects a relative path, 500-multiplexer_spawn-fcgi.pid will work.
While specifying /var/run explicitly works as well, I don't think that we should
do this.

Also, this is rather unfortunate because the pid file name here depends both on
internals of the notificationserver and spawn-fcgi modules. While it doesn't
seem that we can avoid the latter (no way to specify complete PID file name,
only individual parts of it), we definitely can address the former. This
directive should be part of the notificationserver module rather than being set
in Hiera. Also, notificationserver should explicitly specify order => 500 on the
pool rather than implying the default.

[mathias, 2015/10/21 11:44:01]

Why don't you think so? Given the other circumstances, especially that we cannot
really auto-aggregate that path or configure it explicitly, I actually prefer
being explicit in the configuration file at least.
Indeed, an explicit $order should be set, will update the patch-set accordingly.

I also believe that a more sophisticated approach would not require hard-coding
in Hiera in the current fashion, but some sort of service supervisor module to
incorporate where necessary.

However, I do not see any way to implement that based on
sitescripts.management.bin.start_services in a resonable fashion without prior
modification to sitescripts.bin.utils.get_config or sitescripts::configfragment
or both. Unfortunately any reasonable approach I came up with so far is way more
overhead than just coding a new solution from scratch, and either way it will
require more coordination upfront and more excessive testing before roll-out.

I do not consider this effort reasonable right now, especially given the
severity of the intention behind this patch-set. But if you have an idea I may
have overseen, please share it with me.

[Wladimir Palant, 2015/10/21 12:07:06]

I don't think I can follow but - well, I won't insist on relative paths, it's
not worth discussing.
I hope that you will also move the keep_alive_services invocation into
notificationserver module rather than leaving it in Hiera - that was the more
important part.