Ansible usage of puppet "facter" not working in some hosts

[Thomas Spear]

Hi all,

I have an environment setup where we have puppet applying configuration management, and ansible is used to make approved one-off changes.

As part of a playbook, we pull the facter_installed_rpms fact into a variable within the play and check for the presence of a given RPM. This is simpler than using the command module to do rpm -qa, and practically the only way to do this since the rpm module doesn't seem to provide an option to query installed modules without making a change.

In the majority of our hosts, this works fine without issues.

But in a few servers, I'm getting an error from ansible that "facter_installed_rpms" is undefined.

Additionally, when I run "ansible localhost -m setup -a 'gather_subset=!all,!any,facter' " I'm unable to see any facter_* facts in the output, and as such, ansible fails when this fact is not defined.

Whereas on the working host, the above command shows facter_* facts (as documented by the setup module's documentation page)

Notes

Note

• More ansible facts will be added with successive releases. If facter or ohai are installed, variables from these programs will also be snapshotted into the JSON file for usage in templating. These variables are prefixed with facter_ and ohai_ so it’s easy to tell their source. All variables are bubbled up to the caller. Using the ansible facts and choosing to not install facter and ohai means you can avoid Ruby-dependencies on your remote systems. (See also facter and ohai.)

I have narrowed this down to the point where I'm fairly confident that its something in the puppet configuration being sent from the puppet compile masters, rather than the ansible configuration.

The working hosts connect to one set of compile masters while the non-working hosts connect to another different set of compile masters. So I think something in the code (or maybe in the system environment as a result of the puppet code) between the two sets of compile masters is different, but I haven't the faintest idea what it might be.

That being said, I am hoping that I can do some additional probing of the ansible setup module to find out what is different so I can identify the root cause for this discrepancy, but I'm not sure what all I should try.

[Thomas Spear]

To be a bit clearer, I want to know if there is some way to run the setup module in debug mode, so I can get more output on what the module is doing as it tries to gather facts from the system.

I want to do this on the working server so I can compare what its doing when it gathers the puppet facts against what the non-working server is doing when it does NOT gather the puppet facts.

Thanks in advance!

[Kai Stian Olstad]

On 16.06.2019 22:27, Thomas Spear wrote:
> To be a bit clearer, I want to know if there is some way to run the setup
> module in debug mode, so I can get more output on what the module is doing
> as it tries to gather facts from the system.

https://docs.ansible.com/ansible/latest/dev_guide/debugging.html


--
Kai Stian Olstad

[Thomas Spear]

Hello, thanks for the link.

Unfortunately, I am trying to debug the setup module, which is bundled with the app from RedHat. I don't think I would be able to add a breakpoint to that module, least of all on a production system (which, conveniently, is the only place we can replicate this)

Any chance there's a flag I can pass on the command line thats undocumented, that allows me to just turn up the module's verbosity?

Or a something that I can add to the top of a playbook to do the same?

Or some way to call the setup task (gather_facts: no, create a task that calls setup, and pass it a parameter) that can accomplish this?

It seems silly that we can't get more verbosity out of built in modules. I guess each module would have to have an argument added to it to allow for more verbosity? How can I file a bug against the setup module?

Thanks again for your help!

[Kai Stian Olstad]

On 17.06.2019 02:12, Thomas Spear wrote:
> Hello, thanks for the link.
>
> Unfortunately, I am trying to debug the setup module, which is bundled with
> the app from RedHat. I don't think I would be able to add a breakpoint to
> that module, least of all on a production system (which, conveniently, is
> the only place we can replicate this)
>
> Any chance there's a flag I can pass on the command line thats
> undocumented, that allows me to just turn up the module's verbosity?
> Or a something that I can add to the top of a playbook to do the same?
> Or some way to call the setup task (gather_facts: no, create a task that
> calls setup, and pass it a parameter) that can accomplish this?
>
> It seems silly that we can't get more verbosity out of built in modules. I
> guess each module would have to have an argument added to it to allow for
> more verbosity? How can I file a bug against the setup module?

There isn't any fundamental difference between the setup module and any of the other modules bundled with Ansible, so debugging it is the same.

By setting ANSIBLE_KEEP_REMOTE_FILES=1 you can log inn to the host and run the Python script with explode and manually edit and run the script with your changes.

--
Kai Stian Olstad

[Brian Coca]

One note, factor and ohai must support JSON output for the setup
module to be able to use them, so they won't work unless they were
installed with JSON support.

--
----------
Brian Coca

[Thomas Spear]

How can I tell if that's the case? They every server's install should be the same.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/qGO8cwC6RmE/unsubscribe.
To unsubscribe from this group and all its topics, 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/CACVha7cPMUKuL9BbbyQYvQHEWaxj%2Bwb7W4RPAT1PU%3DXCb_pw7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Brian Coca]

depends, some build it from gems with diff options, some have it all
in one package, some have diff packages, normally testing 'facter
--json' should be enough to tell you



--
----------
Brian Coca

[Thomas Spear]

Thanks for that. I just checked and I do get json formatted output with that flag. I'll try to get our ansible infrastructure team to take a look. Thanks again.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/qGO8cwC6RmE/unsubscribe.
To unsubscribe from this group and all its topics, 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/CACVha7cCmNSbdBiReAg-jEJYjHC428a9hG0AJ30RTpmEUuPPsQ%40mail.gmail.com.

[Dan Linder]

Since you have at least one working and one failing machine (presumably of the same OS version), can you compare the "rpm -qa" output and see what's different between the two just in case it's a simple package that was missing?

On Sunday, June 16, 2019 at 2:10:04 PM UTC-5, Thomas Spear wrote:

[Thomas Spear]

Thanks. I'll give that a shot

--

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/qGO8cwC6RmE/unsubscribe.
To unsubscribe from this group and all its topics, 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/239c4f99-8d5a-42c5-b88a-c19d208bd73e%40googlegroups.com.