Application of elasticsearch Ansible role hangs indefinitely adding APT repos (Debian 9)


Hi! I'm trying to install a single-node ES instance on Debian GNU/Linux 9.4 (stretch) using the Ansible role and I see the play hanging in the following task (appears to execute the first item (the old APT repo) and never gets to the second item (new APT repo)):

- name: Debian - Add elasticsearch repository
  become: yes
  apt_repository: repo={{ item.repo }} state={{ item.state}}
    - { repo: "{{ es_apt_url_old }}", state: "absent" }
    - { repo: "{{ es_apt_url }}", state: "present" }
  when: es_use_repository

This is my playbook section for the target host:

- hosts: rezinka
    - { role: elasticsearch,
        es_instance_name: 'node1',
        es_data_dirs: '/data/elasticsearch',
        es_config: {
          node.master: true,
          http.port: 9200,
          transport.tcp.port: 9300,

I have the verbose output from the run of this particular task and result (the first item in the list) until it is interrupted with Ctrl-C here:

Running from Ansible 2.5.2.

Any ideas?

(Michael Russell) #2

Hi @dss

Right now the ansible-elasticsearch role is only being tested with Ubuntu 14.04, 16.04, Debian 8 and Centos 7. I'm going to try and run this locally with Debian 9 to see if this should be working or not. I'll also make sure this lands in the automated pull request testing job.



(Michael Russell) #3

So I was able to run the default playbook against a Debian 9 host just fine and elasticsearch is "running".

Can you check whether or not you can download the package from our download server?



Yep, the package installs fine and starts up and runs. In fact from the playbook it worked if I commented out completed items from the loops and let it creep forward one at a time (package installed and could be configured and started fine).

I ran into the same issue elsewhere in the playbook after manually passing through some of the loop items in the tasks, so it's not specific to what I initially reported. I also don't think it's related to the playbook at all, something specific to my environment more likely. I'm running ansible 2.5.2 on Python 2.7.14 on OpenBSD amd64 and haven't noticed any behavior like this in any playbooks before the 2.5.x update to Ansible.

+1 for idea of adding to automated tests, the Ansible playbook option is very welcome and it would be great for it to be available/reliable going forward.

(system) #5

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.