consul_agent_use_ip: true is not handled properly

marcindulak commented 6 years ago

I have the following inventory and playbook:

dev-consul:
  vars:
    ansible_port: 22
  hosts:
    dev-consul-server1:
      ansible_host: 192.168.123.41
      ipv4_addresses:
        - 192.168.123.41
    dev-consul-server2:
      ansible_host: 192.168.123.42
      ipv4_addresses:
        - 192.168.123.42
    dev-consul-server3:
      ansible_host: 192.168.123.43
      ipv4_addresses:
        - 192.168.123.43

- hosts: dev-consul
  gather_facts: true
  become: yes

  tasks:

  - name: configure consul cluster
    include_role:
      name: andrewrothstein.consul-cluster
      private: yes
    vars:
      - consul_agent_server_group_name: 'dev-consul'
      - consul_agent_network_iface: 'enp0s8'
      - consul_agent_use_ip: true
      - consul_agent_secure: false

with ansible 2.4 and 2.5 I'm getting the error:

TASK [andrewrothstein.consul-cluster : configure templates...] ***********************************************************************************************************************************
fatal: [dev-consul-server1]: FAILED! => {"changed": false, "failed": true, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'consul_agent_network_iface'"}
fatal: [dev-consul-server2]: FAILED! => {"changed": false, "failed": true, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'consul_agent_network_iface'"}
fatal: [dev-consul-server3]: FAILED! => {"changed": false, "failed": true, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'consul_agent_network_iface'"}

This is due to:

unnecessary quotes around consul_agent_network_iface - we want to access the actual value of consul_agent_network_iface
even with unquoted consul_agent_network_iface I believe what we want in https://github.com/andrewrothstein/ansible-consul-cluster/blob/f8be6c70784508ef99f9f83948415fc2ce59818a/vars/main.yml is
```
hostvars[inventory_hostname]['ansible_' + consul_agent_network_iface]['ipv4']['address']
```
instead of

hostvars[inventory_hostname]['ansible_' + hostvars[inventory_hostname]['consul_agent_network_iface']]['ipv4']['address']

The same for the peer part in vars/main.yml.

andrewrothstein commented 6 years ago

First, let me say thanks for caring! Contributing to FOSS often feels like trees falling silently in the woods! I want to make this useful for others and the documentation could definitely use enhancement!

When I wrote this role I was managing a cluster where I needed to control the network interface to use on a host by host basis. Using hostvars[inventory_hostname]['consul_agent_network_iface'] allows for resolution of the consul_agent_network_iface as a host var. If you add a group_vars file for you dev-consul group...

---
# group_vars/dev-consul.yml
consul_agent_network_iface: enp0s8

I think you'll be in business. LMK how it goes. I'm open to adding a simplifying role var that makes the role work the way you thought. Drew

marcindulak commented 6 years ago

Thanks for answering!

The original functionality of setting consul_agent_network_iface per host is good, and works when setting consul_agent_network_iface in the inventory file, it works both per host and group:

dev-consul:
  vars:
    ansible_port: 22
    consul_agent_network_iface: 'host variable takes precedence'
  hosts:
    dev-consul-server1:
      ansible_host: 192.168.123.41
      consul_agent_network_iface: 'enp0s8'
    dev-consul-server2:
      ansible_host: 192.168.123.42
      consul_agent_network_iface: 'enp0s8'
    dev-consul-server3:
      ansible_host: 192.168.123.43
      consul_agent_network_iface: 'enp0s8'

I have a dynamic inventory that does not know about the network interface for consul, and prefer not to scatter the settings across too many files and keep the source code of the role intact, that's why I assumed it is possible to set consul_agent_network_iface at the playbook level, using include_role. What is your suggestion about this possibility?

andrewrothstein / ansible-consul_cluster

consul_agent_use_ip: true is not handled properly #5