Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'dict object' has no attribute u'ansible_eth1' #10

Closed
jmvbxx opened this issue Nov 8, 2016 · 4 comments
Closed

'dict object' has no attribute u'ansible_eth1' #10

jmvbxx opened this issue Nov 8, 2016 · 4 comments

Comments

@jmvbxx
Copy link

jmvbxx commented Nov 8, 2016

Good afternoon, Brian!

I installed your role from Ansible Galaxy and I'm trying to install consul on a standalone server.

Here's basic information:

  • ansible 2.2.0.0
  • Installing on Ubuntu 16.04 (not officially supported)

Full error:

TASK [brianshumate.consul : Bootstrap configuration] ***************************
fatal: [consul]: FAILED! => {"changed": false, "failed": true, "msg": "AnsibleUndefinedVariable: {{ hostvars[inventory_hostname]['ansible_'+consul_iface]['ipv4']['address'] }}: 'dict object' has no attribute u'ansible_eth1'"}

The playbook:

  - hosts: "consul"
    gather_facts: true
    become: yes
    vars:
      consul_node_role: "bootstrap" 
    roles:
    - { role: brianshumate.consul, tags: ["consul"] }

ansible.cfg

[defaults]
host_key_checking = False

Thanks in advance!

@brianshumate
Copy link
Contributor

brianshumate commented Nov 8, 2016

Hey there, Jason!

Thanks for the report.

It looks like you're hitting that error because your server(s) have just one network interface and the role currently expects two, but I should be able to add something to make it work in either case.

Just to clarify one other point, are you also just starting up one instance of Consul? This is generally discouraged, so the role is designed for at least 3 servers so there would also need to be something added if for example you wanted to just start one server in -dev mode.

@jmvbxx
Copy link
Author

jmvbxx commented Nov 9, 2016

Thanks for your reply! For prod I never run fewer than three consul server instances but in this test case I had only set one up.

It appears you're correct. Here is the setup of the AWS instance:

[email protected]:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 06:29:ac:5f:ad:cd  
          inet addr:xxx.xx.xx.xxx  Bcast:xxx.xx.xx.xxx  Mask:255.255.240.0
          inet6 addr: fe80::429:acff:fe5f:adcd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
          RX packets:102739 errors:0 dropped:0 overruns:0 frame:0
          TX packets:55552 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:137727440 (137.7 MB)  TX bytes:4140894 (4.1 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:164 errors:0 dropped:0 overruns:0 frame:0
          TX packets:164 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:12104 (12.1 KB)  TX bytes:12104 (12.1 KB)

@brianshumate
Copy link
Contributor

Okay, so this issue is not really about having only one interface as the role should work fine that way, but due to how the role works with Vagrant based VirtualBox instances, it expects the intra-cluster communications to occur on the secondary interface or eth1 by default.

This is not set in stone however, and you can actually specify your own name for the preferred cluster communication interface with the consul_iface variable.

Taking your playbook and making this modification should work as expected:

  - hosts: "consul"
    gather_facts: true
    become: yes
    vars:
      consul_node_role: "bootstrap" 
    roles:
    - { role: brianshumate.consul, consul_iface: "eth0", tags: ["consul"] }

Can you confirm that this works for you?

@brianshumate
Copy link
Contributor

brianshumate commented Nov 12, 2016

Hi Jason,

Hopefully specifying a different consul_iface got you past this issue. At any rate, I have created an enhancement in #13 to make this problem more clear to users going forward, so I am going to close this.

Thanks again for the report!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants