[PATCH 1/2] Move service start to the end (after we did set it up)

[Michael Scherer]

From: Michael Scherer <misc(a)zarb.org&gt;

Also remove notify for handler for service, since the service
will be started by service, no need to notify a handler to restart
it.
---
 roles/fedmsg/gateway/tasks/main.yml | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/roles/fedmsg/gateway/tasks/main.yml b/roles/fedmsg/gateway/tasks/main.yml
index 86bece4..cd34b26 100644
--- a/roles/fedmsg/gateway/tasks/main.yml
+++ b/roles/fedmsg/gateway/tasks/main.yml
@@ -15,14 +15,6 @@
   tags:
   - fedmsgmonitor
 
-- name: enable on boot and start fedmsg-gateway
-  service: name=fedmsg-gateway state=started enabled=true
-  tags:
-  - services
-  - fedmsg/gateway
-  notify:
-  - restart fedmsg-gateway
-
 - name: setup fedmsg-gateway config file
   copy: src=gateway.py dest=/etc/fedmsg.d/gateway.py
   tags:
@@ -40,3 +32,9 @@
   - fedmsg/gateway
   notify:
   - restart fedmsg-gateway
+
+- name: enable on boot and start fedmsg-gateway
+  service: name=fedmsg-gateway state=started enabled=true
+  tags:
+  - services
+  - fedmsg/gateway
-- 
1.8.3.1

[PATCH 2/2] Do not override the complete systemd config

[Michael Scherer]

From: Michael Scherer <misc(a)zarb.org&gt;

using the drop-in config snipper system, we can add
configuration to systemd without replacing it, in case
the systemd file is changed upstream.
---
 roles/fedmsg/gateway/files/fedmsg-gateway.service | 15 ---------------
 roles/fedmsg/gateway/files/fs-limits.conf         |  2 ++
 roles/fedmsg/gateway/tasks/main.yml               | 11 ++++++++---
 3 files changed, 10 insertions(+), 18 deletions(-)
 delete mode 100644 roles/fedmsg/gateway/files/fedmsg-gateway.service
 create mode 100644 roles/fedmsg/gateway/files/fs-limits.conf

diff --git a/roles/fedmsg/gateway/files/fedmsg-gateway.service
b/roles/fedmsg/gateway/files/fedmsg-gateway.service
deleted file mode 100644
index a72436c..0000000
--- a/roles/fedmsg/gateway/files/fedmsg-gateway.service
+++ /dev/null
@@ -1,15 +0,0 @@
-[Unit]
-Description=Outbound fedmsg gateway
-After=network.target
-Documentation=http://fedmsg.readthedocs.org/en/latest/commands/
-
-[Service]
-ExecStart=/usr/bin/fedmsg-gateway
-Type=simple
-User=fedmsg
-Group=fedmsg
-LimitNOFILE=160000
-Restart=on-failure
-
-[Install]
-WantedBy=multi-user.target
diff --git a/roles/fedmsg/gateway/files/fs-limits.conf
b/roles/fedmsg/gateway/files/fs-limits.conf
new file mode 100644
index 0000000..c31a466
--- /dev/null
+++ b/roles/fedmsg/gateway/files/fs-limits.conf
@@ -0,0 +1,2 @@
+[Service]
+LimitNOFILE=160000
diff --git a/roles/fedmsg/gateway/tasks/main.yml b/roles/fedmsg/gateway/tasks/main.yml
index cd34b26..6a82726 100644
--- a/roles/fedmsg/gateway/tasks/main.yml
+++ b/roles/fedmsg/gateway/tasks/main.yml
@@ -23,10 +23,15 @@
   notify:
   - restart fedmsg-gateway
 
-- name: bump fs limits by installing our own systemd service file
+- name: create systemd drop-in directory
+  file: >
+    dest=/etc/systemd/system/fedmsg-gateway.service.d
+    state=directory
+
+- name: bump fs limits by installing a drop-in systemd config
   copy: >
-    src=fedmsg-gateway.service
-    dest=/usr/lib/systemd/system/fedmsg-gateway.service
+    src=fs-limits.conf
+    dest=/etc/systemd/system/fedmsg-gateway.service.d/fs-limits.conf
   tags:
   - config
   - fedmsg/gateway
-- 
1.8.3.1

[PATCH 2/2] Do not override the complete systemd config

[Kevin Fenzi]

This one I am not sure about how best to handle. 

If we simply apply this and run it we have the modified service files
still around. Perhaps we could do this in 2 steps? Replace the service
file with the one from the package, then after everyplace is updated,
remove that?

Or I suppose we could reinstall the package, but that might cause other
issues. 

kevin

[PATCH 2/2] Do not override the complete systemd config

[Michael Scherer]

On Mon, Apr 04, 2016 at 01:26:28PM -0600, Kevin Fenzi wrote:
>  This one I am not sure about how best to handle. 
>  
>  If we simply apply this and run it we have the modified service files
>  still around. Perhaps we could do this in 2 steps? Replace the service
>  file with the one from the package, then after everyplace is updated,
>  remove that? 
 
>  Or I suppose we could reinstall the package, but that might cause
> other
>  issues. 
>  
>  kevin 
IIRC, the config in /usr is less prioritary than the one in /etc, so keeping the old
one in /usr should not cause any issues, and will solve itself with next package 
upgrade or reinstallation of the server. 

Since that's for fedmsg-gateway, i suspect that we will one day commit code to it
and upgrade anyway.

-- 
Michael Scherer

[PATCH 2/2] Do not override the complete systemd config

[Kevin Fenzi]

On Mon, 4 Apr 2016 22:06:46 +0200
Michael Scherer <misc(a)zarb.org&gt; wrote:

>  On Mon, Apr 04, 2016 at 01:26:28PM -0600, Kevin Fenzi wrote:
>  > This one I am not sure about how best to handle. 
>  > 
>  > If we simply apply this and run it we have the modified service
>  > files still around. Perhaps we could do this in 2 steps? Replace
>  > the service file with the one from the package, then after
>  > everyplace is updated, remove that?  
>   
>  > Or I suppose we could reinstall the package, but that might cause
>  > other issues. 
>  > 
>  > kevin  
>  
>  IIRC, the config in /usr is less prioritary than the one in /etc, so
>  keeping the old one in /usr should not cause any issues, and will
>  solve itself with next package upgrade or reinstallation of the
>  server. 
>  
>  Since that's for fedmsg-gateway, i suspect that we will one day
>  commit code to it and upgrade anyway. 
Well, I don't like the idea of the machines being in a state thats not
described by the playbooks. Sure, it will go back on upgrade, just rubs
me the wrong way. ;) 

kevin

[PATCH 2/2] Do not override the complete systemd config

[Michael Scherer]

On Mon, Apr 04, 2016 at 02:45:51PM -0600, Kevin Fenzi wrote:
>  On Mon, 4 Apr 2016 22:06:46 +0200
>  Michael Scherer <misc(a)zarb.org&gt; wrote:
>  
>  > On Mon, Apr 04, 2016 at 01:26:28PM -0600, Kevin Fenzi wrote:
>  > > This one I am not sure about how best to handle. 
>  > > 
>  > > If we simply apply this and run it we have the modified service
>  > > files still around. Perhaps we could do this in 2 steps? Replace
>  > > the service file with the one from the package, then after
>  > > everyplace is updated, remove that?  
>  >  
>  > > Or I suppose we could reinstall the package, but that might cause
>  > > other issues. 
>  > > 
>  > > kevin  
>  > 
>  > IIRC, the config in /usr is less prioritary than the one in /etc, so
>  > keeping the old one in /usr should not cause any issues, and will
>  > solve itself with next package upgrade or reinstallation of the
>  > server. 
>  > 
>  > Since that's for fedmsg-gateway, i suspect that we will one day
>  > commit code to it and upgrade anyway.
>  
>  Well, I don't like the idea of the machines being in a state thats not
>  described by the playbooks. Sure, it will go back on upgrade, just rubs
>  me the wrong way. ;)  
So, since the fix is just yum reinstall of the package, we can either do that
with a adhoc run, a playbook or adding code to the role. I am not keen on adding
code to git just for a 1 off task and remove it just after, but if you think that's
better, i can add it.

-- 
Michael Scherer

[PATCH 2/2] Do not override the complete systemd config

[Kevin Fenzi]

On Mon, 4 Apr 2016 23:11:00 +0200
Michael Scherer <misc(a)zarb.org&gt; wrote:

>  
>  So, since the fix is just yum reinstall of the package, we can either
>  do that with a adhoc run, a playbook or adding code to the role. I am
>  not keen on adding code to git just for a 1 off task and remove it
>  just after, but if you think that's better, i can add it. 
Well, I wanted to confirm that in fact a reinstall would be safe
first. ;) 

Turns out it is, and also, this change only affects our busgateway
servers, not as widespread as I was first thinking. ;) 

So, I went and applied it and reinstalled on those few servers. 

kevin

[Kevin Fenzi]

Applied. 

kevin