QA: why is the reload systemd configuration needed explicitly

[grzegorznowak]

Hey guys, in this file/line:

ansible-elasticsearch/handlers/main.yml

Line 2 in fb760f4

- name: reload systemd configuration

reload of the underlying service agent should be handled by the service module, so why we need that ?

[Crazybus]

It looks like this workaround was added before the systemd module gained support for the daemon reload.

Are you sure that the service module does support doing a systemd daemon reload? I can't find any reference to it in the ansible source code or documentation.

[grzegorznowak]

hey @Crazybus , I'm doing similar stuff in my roles normally, ie:
https://github.com/grzegorznowak/ansible-redis/blob/master/tasks/instance-config.yml
so uploading a custom service config file and then enabling it with the enabled=true param to the service module.
The one linked to have test coverage in for Debians (@see https://github.com/grzegorznowak/ansible-redis/blob/master/molecule/default/molecule.yml#L8) and it works reliably in the flavours from the link. Not sure which other family would have systemctl anyway, but if so Ansible should handle that trasparently. Also maybe a matter of ansible version (I'm usually using latest stable), so definitely need to double check that with various Ansibles.

[nickhammond]

I'm having issues with this as well, don't really have a solution yet. I also tried swapping out the command task with the native systemd module but ended up still having issues. Reloading configuration and services is usually handed via the service module but it looks like that's no longer the direction moving forward.

RUNNING HANDLER [elastic.elasticsearch : reload systemd configuration] *********
fatal: [localhost]: FAILED! => {"changed": true, "cmd": ["systemctl", "daemon-reload"], "delta": "0:00:00.015694", "end": "2018-11-13 00:00:10.481827", "msg": "non-zero return code", "rc": 1, "start": "2018-11-13 00:00:10.466133", "stderr": "Failed to connect to bus: No such file or directory", "stderr_lines": ["Failed to connect to bus: No such file or directory"], "stdout": "", "stdout_lines": []}

Going to do some more digging but I'd guess it's also an issue with the init file for ES within systemd too. This is utilizing Docker(ubuntu:xenial) and running an Ansible playbook within that with this playbook.

[grzegorznowak]

@nickhammond this topic is more of a QA request, but just so it happens I did have exactly the same set of issues you are facing elsewhere, so let me just answer that:

systemd is no go on docker I'm afraid. Not that I tried everything but was close to, and that still didn't work. There are topics covering that, and in basis you have to have a docker base image built with systemd bus in place and/or privileged container, but even that wasn't working reliably.

My general manifest is that docker is not exactly suited to be provisioned by ansible (except for specific cases where it works of course ), and as the general approach it wants you to use single machine per service. So just find one that has ES already installed and add it to your dockerfile and configs I'd say.

[nickhammond]

@grzegorznowak Ah, so I'm not the only one. That makes sense that it's Docker specific too as I'm provisioning in a Vagrant VM and it works fine. I'll tweak how that's running in the CI and go from there, thanks much!

[dovry]

I've been using this

 - name: reload systemd daemon
   systemd:
     daemon_reload: true

in my elasticsearch role at work for a while now. Can confirm it works.