Systemd override for Varnish #33

New Issue

Open

opened 2019-03-21 15:26:13 +01:00 by jlecour · 1 comment

jlecour commented

2019-03-21 15:26:13 +01:00

Owner

Issue imported from forge.evolix.org on 2019-03-21 14:26:13

Project: ansible-roles

Issue: 2165

Tracker: Evolution

Status: Commentaire

Author: Jérémy L.

Category: varnish

Started at: 2017-03-16 00:00:00

Done ratio: 0

Created at: 2017-03-16 07:57:52

Updated at: 2017-08-23 00:30:41

With this task, the override was not working :

- name: Modify Varnish configuration files
  ini_file:
    dest: /etc/systemd/system/varnish.service.d/varnish.service
    section: Service
    option: "{{ item.option }}"
    value: "{{ item.value }}"
   notify: reload systemctl
  with_items:
    - { option: ExecStart, value: "/usr/sbin/varnishd -a 0.0.0.0:80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,{{ malloc }} -p thread_pools={{ thread_pools }} -p thread_pool_add_delay=2 -p thread_pool_min=500 -p thread_pool_max=5000 "}
    - { option: ExecReload, value: "/etc/varnish/reload-vcl.sh" }

The commit commit:6b3b693 changed the file name to varnish.conf instead of varnish.service, but apparently the issue remained, hence the fix in commit:4be248c to simply copy the file.

I can see 2 issues here :

This is a copy and not a template so we lose the variables in the configuration. It's easy to fix with a template. But this is not compatible with other modifications made out of Ansible. If a file already exists when Ansible runs, it is either ignored (force: false) or written over (force: yes).

I suggest we make sure that the file is present (with a touch, for example) then we keep the ini_file approach which respects other values in the file.
When we move to Ansible 2.2, we can use the create: yes attribute of the module to create the file if it doesn't already exist (see http://docs.ansible.com/ansible/ini_file_module.html).

> **Issue imported from forge.evolix.org on 2019-03-21 14:26:13** > * Project: ansible-roles > * Issue: 2165 > * Tracker: Evolution > * Status: Commentaire > * Author: Jérémy L. > * Category: varnish > * Started at: 2017-03-16 00:00:00 > * Done ratio: 0 > * Created at: 2017-03-16 07:57:52 > * Updated at: 2017-08-23 00:30:41 With this task, the override was not working : - name: Modify Varnish configuration files ini_file: dest: /etc/systemd/system/varnish.service.d/varnish.service section: Service option: "{{ item.option }}" value: "{{ item.value }}" notify: reload systemctl with_items: - { option: ExecStart, value: "/usr/sbin/varnishd -a 0.0.0.0:80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,{{ malloc }} -p thread_pools={{ thread_pools }} -p thread_pool_add_delay=2 -p thread_pool_min=500 -p thread_pool_max=5000 "} - { option: ExecReload, value: "/etc/varnish/reload-vcl.sh" } The commit commit:6b3b693 changed the file name to `varnish.conf` instead of `varnish.service`, but apparently the issue remained, hence the fix in commit:4be248c to simply copy the file. I can see 2 issues here : This is a copy and not a template so we lose the variables in the configuration. It's easy to fix with a template. But this is not compatible with other modifications made out of Ansible. If a file already exists when Ansible runs, it is either ignored (`force: false`) or written over (`force: yes`). I suggest we make sure that the file is present (with a touch, for example) then we keep the `ini_file` approach which respects other values in the file. When we move to Ansible 2.2, we can use the `create: yes` attribute of the module to create the file if it doesn't already exist (see http://docs.ansible.com/ansible/ini_file_module.html).

gcolpart commented

2019-03-21 15:26:13 +01:00

Owner

Comment imported from forge.evolix.org on 2019-03-21 14:26:13

Author: Gregory C.

Created at: 2017-08-23 00:30:41

Status: Nouveau → Commentaire

I propose to use force: no to be as safe as possible.

> **Comment imported from forge.evolix.org on 2019-03-21 14:26:13** > * Author: Gregory C. > * Created at: 2017-08-23 00:30:41 > * Status: Nouveau → Commentaire I propose to use force: no to be as safe as possible.