Today we have three VERY interesting pull requests, which I have
merged into the development branch. All 3 need
your help testing! I said this project is moving fast right? This
is a GREAT example. The pace at which things happen
here is blowing me away, so thanks a tremendous amount for making this possible.
Anyway, without further ado, here's today's developments:
(1)
Jeroen Hoekx brings us a nice patch to allow any module to contribute
facts. The setup module will still be called automatically by the
playbook, but if you want facter facts and ohai facts to be accessible
as variables you will need to do the following:
tasks:
- action: ohai
- action: facter
Otherwise, for performance reasons, they will NOT be called. This is
made possible by the fact that we have Ansible facts now (sfromm's
very nice patch) so I hope this is not controversial. If you are
using 0.3 and want to future proof yourself now so you don't forget,
you can go ahead and add the "action: ohai/facter" steps, and it won't
do much, but it won't hurt you now. I strongly believe we won't need
any non-Ansible facts and folks should look at switching over. I have
a 0.3 doc item to include the list of stock facts on the web page.
We'll need to include this docs and mention it requires 0.4
https://github.com/ansible/ansible/pull/209
Since this is kind of a playbook API break (a very very minor one),
thoughts on this are welcome. Do you think setup should still call
ohai and facter modules automatically if installed, or not?
Hi,
Some clarifications:
Jeroen Hoekx brings us a nice patch to allow any module to contribute
facts. The setup module will still be called automatically by the
playbook, but if you want facter facts and ohai facts to be accessible
as variables you will need to do the following:
tasks:
- action: ohai
- action: facter
Otherwise, for performance reasons, they will NOT be called. This is
made possible by the fact that we have Ansible facts now (sfromm's
very nice patch) so I hope this is not controversial. If you are
using 0.3 and want to future proof yourself now so you don't forget,
you can go ahead and add the "action: ohai/facter" steps, and it won't
do much, but it won't hurt you now. I strongly believe we won't need
any non-Ansible facts and folks should look at switching over. I have
a 0.3 doc item to include the list of stock facts on the web page.
The ohai and facter modules already existed before. I just changed
them to use the new json return layout. But we should probably rewrite
them to use the same variable naming conventions as used in the setup
module (prefix with facter_ or ohai_).
Ohai and facter are currently still run in the setup module if they
are on the system. So you don't have to add them to the playbook.
Greetings,
Jeroen
Hi,
Some clarifications:
Jeroen Hoekx brings us a nice patch to allow any module to contribute
facts. The setup module will still be called automatically by the
playbook, but if you want facter facts and ohai facts to be accessible
as variables you will need to do the following:
tasks:
- action: ohai
- action: facter
Otherwise, for performance reasons, they will NOT be called. This is
made possible by the fact that we have Ansible facts now (sfromm’s
very nice patch) so I hope this is not controversial. If you are
using 0.3 and want to future proof yourself now so you don’t forget,
you can go ahead and add the “action: ohai/facter” steps, and it won’t
do much, but it won’t hurt you now. I strongly believe we won’t need
any non-Ansible facts and folks should look at switching over. I have
a 0.3 doc item to include the list of stock facts on the web page.
The ohai and facter modules already existed before. I just changed
them to use the new json return layout. But we should probably rewrite
them to use the same variable naming conventions as used in the setup
module (prefix with facter_ or ohai_).
Hmm, so the new layout is to wrap them in “ansible_facts” as a dictionary? This seems unnecessary if the setup module is going to call them.
I doubt anyone is using them via the API but we should not change data structures if we can avoid it.
Maybe explain more about this?
Ohai and facter are currently still run in the setup module if they
are on the system. So you don’t have to add them to the playbook.
Very good!
The ohai and facter modules already existed before. I just changed
them to use the new json return layout. But we should probably rewrite
them to use the same variable naming conventions as used in the setup
module (prefix with facter_ or ohai_).
Hmm, so the new layout is to wrap them in "ansible_facts" as a dictionary?
This seems unnecessary if the setup module is going to call them.
That's correct. The setup module doesn't use these modules.
I doubt anyone is using them via the API but we should not change data
structures if we can avoid it.
Maybe explain more about this?
Thinking about it, wrapping these modules is probably unnecessary. I
will send in a patch to revert the changes to the ohai and facter
modules.
Jeroen