Ansible facts help (ansible_fqdn)

3,763 views
Skip to first unread message

Nicolas G

unread,
Nov 20, 2014, 11:18:58 AM11/20/14
to ansible...@googlegroups.com
Hi,

I"m trying to use Ansible magic var inventory_hostname along with ansible_fqdn fact. I have a playbook that will update the hostname of the system based on the entry in the inventory file and later it will use ansible_fqdn value to configure a file.

Unfortunately the ansible_fqdn keeps the initial value when I start running the plabook even if later on I manually gather facts again. The correct value is displayed if I run the same playbook again after the first run. It seems to me that for some reason the manual facts gathering (setup:) is not working :

"""
- hosts: all
  tasks:

  - name: Gathering Ansible facts
    setup:
 
  - name: update the hostname
    hostname: name="{{ inventory_hostname }}"

  - name: boot persist the hostname
    lineinfile: dest=/etc/sysconfig/network
              regexp=^HOSTNAME=
              line=HOSTNAME={{ inventory_hostname }}
              state=present

  - name: add the hostname to the hosts file
    lineinfile: dest=/etc/hosts
              regexp="^127\.0\.0\.1(.*)"
              line="127.0.0.1{{'\t'}}{{ inventory_hostname }} localhost.localdomain localhost"
              state=present
              backrefs=yes

  - name: Print ansible_fqdn
    debug: msg="ansible_fqdn is {{ ansible_fqdn }}"

"""

Any ideas ??

Regards,
N.

Nicolas G

unread,
Nov 20, 2014, 11:22:02 AM11/20/14
to ansible...@googlegroups.com
Sorry , the correct playbook is the one bellow, the setup module executed before the debug action at the end:

"""
- hosts: all
  tasks:
 

James Cammarata

unread,
Nov 20, 2014, 11:22:16 AM11/20/14
to ansible...@googlegroups.com
Hi Nicholas, in your example above, the manual use of the setup module would have to come after the hostname entry is changed in the file. Alternatively, you could simply use a call to set_fact to override that value, so that you don't have to regather all of the facts.


--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/400627b7-9b02-45fd-bf77-579c3c87e27d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

James Cammarata

unread,
Nov 20, 2014, 11:26:42 AM11/20/14
to ansible...@googlegroups.com
Which connection type are you using? If you're using the default ("smart"), which will use SSH on most recent versions of Linux (Fedora, Ubuntu) and Mac OSX, the ControlPersist option will leave the SSH connection open to the target host, so the current hostname of the session will continue to be used. As I said previously, I would recommend using set_fact so you don't have to re-gather facts in this situation.

Thanks!

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

Nicolas G

unread,
Nov 20, 2014, 11:53:39 AM11/20/14
to ansible...@googlegroups.com
Thanks a lot James, I guess I'm using the default connection type. 

Didn't know I could use set_fact to override discovered values, that will be quite handy .

Regards,
N.

Nicolas G

unread,
Nov 20, 2014, 12:47:32 PM11/20/14
to ansible...@googlegroups.com
I'm trying to set ansible_fqdn using set_fact but the task doesn't seem to be executed  :


- name: set ansible_fqdn fact
  set_fact: ansible_fqdn={{ inventory_hostname }}


# output :
TASK: [common | set ansible_fqdn fact] ****************************************
ok: [server1.example.net] => {"ansible_facts": {"ansible_fqdn": "server1.example.net"}}


Any clue ? 

On Thursday, November 20, 2014 6:26:42 PM UTC+2, James Cammarata wrote:

Brian Coca

unread,
Nov 20, 2014, 12:55:48 PM11/20/14
to ansible...@googlegroups.com
task seems to be executed, what result were you expecting?




--
Brian Coca

Nicolas G

unread,
Nov 20, 2014, 1:05:14 PM11/20/14
to ansible...@googlegroups.com
I'm expecting ansible_fqdn to have the same value as inventory_hostname , see my test playbook and output bellow :

"""
- name: show inventory_hostname
  debug: msg="inventory_hostname is  {{ inventory_hostname }}"

- name: show ansible_fqdn
  debug: msg="ansible_fqdn is  {{ ansible_fqdn }}"
- name: set ansible_fqdn fact
  set_fact: ansible_fqdn={{ inventory_hostname }}

- name: show ansible_fqdn
  debug: msg="ansible_fqdn is  {{ ansible_fqdn }}"


#####


PLAY [all] ******************************************************

GATHERING FACTS ***************************************************************

TASK: [common | show inventory_hostname] **************************************
    "msg": "inventory_hostname is  server1.example.net"
}

TASK: [common | show ansible_fqdn] ********************************************
    "msg": "ansible_fqdn is  ip-10-182-192-10.ec2.internal"
}

TASK: [common | set ansible_fqdn fact] ****************************************
ok: [server1.example.net] => {"ansible_facts": {}}

TASK: [common | show ansible_fqdn] ********************************************
    "msg": "ansible_fqdn is  ip-10-182-192-10.ec2.internal"
}

PLAY RECAP ********************************************************************
server1.example.net       : ok=5    changed=0    unreachable=0    failed=0


Kind regards,
N.

Brian Coca

unread,
Nov 20, 2014, 1:15:52 PM11/20/14
to ansible...@googlegroups.com
this 2nd output shows ansible_facts not returning anything, unlike
your previous output.

but ran a test with my own system copying and pasting your last
playbook and I get this:

PLAY [localhost] **************************************************************

GATHERING FACTS ***************************************************************
ok: [localhost]

TASK: [show inventory_hostname] ***********************************************
ok: [localhost] => {
"msg": "inventory_hostname is localhost"
}

TASK: [show ansible_fqdn] *****************************************************
ok: [localhost] => {
"msg": "ansible_fqdn is workstation.briancoca.local"
}

TASK: [set ansible_fqdn fact] *************************************************
ok: [localhost]

TASK: [show ansible_fqdn] *****************************************************
ok: [localhost] => {
"msg": "ansible_fqdn is localhost"
}

PLAY RECAP ********************************************************************
localhost : ok=5 changed=0 unreachable=0 failed=0

what version of ansible are you using?
--
Brian Coca

Nicolas G

unread,
Nov 20, 2014, 4:15:49 PM11/20/14
to ansible...@googlegroups.com
I think I found the most weird bug that was driving me crazy, it seems for some strange reason when you have in your playbook vars_files with the name based on a variable the ansible_fqdn keeps the old value...

Here are all the steps to reproduce it in ansible 1.7.1 :

create the bellow 3 files exactly as they are (var_test.yml , inv_test, test.yml) :

1) var_test.yml :
TEST: "HELLO"

2) inv_test :
[all:vars]
VAR_FILE=var_test

[test]
test

3) test.yml :
---
- hosts: localhost
  vars_files:
    - "{{ VAR_FILE }}.yml"

  tasks:

    - name: show inventory_hostname
      debug: msg="inventory_hostname is  {{ inventory_hostname }}"

    - name: show ansible_fqdn
      debug: msg="ansible_fqdn is  {{ ansible_fqdn }}"

    - name: set ansible_fqdn fact
      set_fact: ansible_fqdn={{ inventory_hostname }}

    - name: show ansible_fqdn
      debug: msg="ansible_fqdn is  {{ ansible_fqdn }}"


4) run ->  ansible-playbook -i inv_test  test.yml -v 


if you replace the - "{{ VAR_FILE }}.yml" with  - var_test.yml it will work
if the var_test.yml is empty it will work  


Regards,
N.

James Cammarata

unread,
Nov 20, 2014, 5:13:42 PM11/20/14
to ansible...@googlegroups.com
Ahh yes, this was a bug in 1.7.x which has been fixed in devel and will be included in 1.8.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

Nicolas G

unread,
Nov 20, 2014, 5:22:03 PM11/20/14
to ansible...@googlegroups.com
What's the ETA for 1.8 ?

Drew Michel

unread,
Nov 24, 2014, 11:47:36 PM11/24/14
to ansible...@googlegroups.com
I'm also curious when 1.8 is planning to be released
Reply all
Reply to author
Forward
0 new messages