While working on a patch to add facts to the setup module, I’d like to get a sense of what facts/ohais people use now. Currently, I’m planning support for distribution, distribution release, architecture, hostname, fqdn, and ip address. Are there other facts that people commonly use or would like to see ansible provide?
sf
I asked this question a while back and Dag Weers had a list of things he thought of:
I also think it’s a bit much to start with, and some are not immediately important.
(Ignore my implementation note comments on that thread, as they are a bit out of date.)
Anyway, I would be more than ok with starting with a small set.
For me, I mostly want all the network address/hostname information, the OS family (CentOS/Ubuntu/FreeBSD), and the OS release (which could just return “FIXME” for the ones you don’t have access to initially and we can upgrade it). I think that would be the minimum for including the feature.
One things to watch out for – the varReplace function right now is pretty basic though, so anything that is NOT flat namespaced would have to be accessed like {{ variable[‘subelement’] }} it’s not like you could do $variable[‘subelement’]. That may be an argument for trying to keep the namespace flat like facter versus nested like ohai does. There are pluses and minuses, but I’d like to be able to keep using the simple variable notation when possible, at least in playbooks.
Take a cue from facter.
ip_eth0
nm_eth0
etc etc etc
-sv
This is also exactly what Cobbler did for a while before network interfaces back in the day.
Structuring the network interfaces were one of Cobbler’s more complicated ideas,
for what it did to templates that used them. It was ok for the code, it was rough to templates
that needed access to them.
There can be a variable that lists the available interfaces, for easy looping.
ansible_interfaces = [ ‘eth0’, ‘eth1’, … ]
I asked this question a while back and Dag Weers had a list of things he thought of:
I also think it’s a bit much to start with, and some are not immediately important.
Ah, thanks for pointing out that thread.
One things to watch out for – the varReplace function right now is pretty basic though, so anything that is NOT flat namespaced would have to be accessed like {{ variable[‘subelement’] }} it’s not like you could do $variable[‘subelement’]. That may be an argument for trying to keep the namespace flat like facter versus nested like ohai does. There are pluses and minuses, but I’d like to be able to keep using the simple variable notation when possible, at least in playbooks.
I was looking at keeping the namespace flat.
sf