Is there a mechanism to be able to get at the facts (from the setup
module) within a module?
Nigel.
Nigel Metheringham wrote:
Is there a mechanism to be able to get at the facts (from the setup
module) within a module?
Not unless you pass them as arguments to the module.
Daniel
> Is there a mechanism to be able to get at the facts (from the setup
> module) within a module?Not unless you pass them as arguments to the module.
There was a time when Ansible retained the facts from `setup' in a file
on the managed node, but that went away several months ago.
Would it be an idea to implement something like
gather_facts: store
to mean run `setup' and leave facts in a predefined/configurable file on
the node? If configurable, it would supposedly mean carrying an
ansible.cfg parameter into the runner (no idea how to do that -- I think
Michael said that would be difficult to do). If predefined, it could be
called `setup.json' or something and remain in $ANSIBLE_TMP on the node.
Regards,
-JP
> Is there a mechanism to be able to get at the facts (from the setup
> module) within a module?Not unless you pass them as arguments to the module.
There was a time when Ansible retained the facts from `setup' in a file
on the managed node, but that went away several months ago.Would it be an idea to implement something like
gather_facts: store
to mean run `setup' and leave facts in a predefined/configurable file on
the node? If configurable, it would supposedly mean carrying an
ansible.cfg parameter into the runner (no idea how to do that -- I think
Michael said that would be difficult to do). If predefined, it could be
called `setup.json' or something and remain in $ANSIBLE_TMP on the node.
I really don't want to do this at this time, it seems sufficient to
pass variables to the module to get explicitly what you need, and that
also leaves
a record of the configuration in the playbook, which I believe is important.
Michael DeHaan wrote:
I really don't want to do this at this time, it seems sufficient to
pass variables to the module to get explicitly what you need, and that
also leaves
a record of the configuration in the playbook, which I believe is important.
The use case for this is that I am hacking around with the user module
to make it work for other OS variants, and was planning on re-using the
more detailed OS description info from the setup module to select the
correct module, rather than either get the user to pass stuff in (hmm...
wonder if I should let them override?), or re-implement the appropriate
code.
Its only two variables right now - really only one as platform.system is
pretty damn standard, but linux (and maybe other?) distribution is a
bit more tweakable, and having this derived in 2 separate places is
another way of having problems later.
Maybe it could be worth pushing that code into the overall module
support utils, before there are modules that change implementation
depending on the system they run on?
Nigel.
The use case for this is that I am hacking around with the user module
to make it work for other OS variants, and was planning on re-using the
more detailed OS description info from the setup module to select the
correct module, rather than either get the user to pass stuff in (hmm...
wonder if I should let them override?), or re-implement the appropriate
code.
Yeah, this is not how we are going to do this.
What we're going to do, like the way we handled many modules wanting
to do file ops, is to move the OS detect function into
lib/ansible/module_common.py
Then we just make each module more or less organized like the
class-based system in the setup module, so it chooses
the right implementation based on the OS detection result.
Maybe it could be worth pushing that code into the overall module
support utils
Now you've got it 