Providing some "facts" for free / which do you use for config today?

Archives Ansible Project
1

We can leverage ohai or JSON installed on the system to power conditional imports, variable substistutions, and even tempting.

We can also use our own ‘setup’ system to push variables down to the system (which is used behind the scenes by play books)

What we don’t have are some “in the box” facts, so ohai/facter are currently required to get things like the OS version.

My question to people looking at this project form a Puppet/Chef perspective is this… what sort of facts/“ohais” do you actually use in your recipes?

We can add many of these to be generated by the setup module for free, thus making the need to install ruby on your nodes go away for most use cases?

Thinking of the ones I actually might use:
fqdn
hostname
operatingsystem
os_version

What else?

This would be a super-easy thing to add to library/setup.

–Michael

2

Thinking of my own projects, the following information has been used in conditional scripts:

  - architecture
  - distribution
  - distribution version
  - distribution release
  - hardware vendor
  - hardware model
  - type of system (physical, blade, virtual)
  - type of virtualization (vmware, kvm, ...)
  - version of vmware host (based on dmi information of guest)
  - network location (customer/datacenter/tier/vpn based on network information)
  - environment (production/staging/... based on naming standard/network information)
  - country (based on naming standard/network information)

We also had some scripts for licensing purposes or for generating configurations that used:

  - number of sockets
  - number of cores
  - number of logical cpus
  - total memory
  - number of nics

I would expect it is possible to create facts based on custom criteria, especially those based on network information, naming conventions or even other sources (on the system or external).

So having a modular environment to plug in logic into library/setup seems very useful to me.

Kind regards,

3

Thinking of my own projects, the following information has been used in
conditional scripts:

  • architecture
  • distribution
  • distribution version
  • distribution release
  • hardware vendor
  • hardware model
  • type of system (physical, blade, virtual)
  • type of virtualization (vmware, kvm, …)
  • version of vmware host (based on dmi information of guest)
  • network location (customer/datacenter/tier/vpn based on network information)
  • environment (production/staging/… based on naming standard/network information)
  • country (based on naming standard/network information)

We also had some scripts for licensing purposes or for generating
configurations that used:

  • number of sockets
  • number of cores
  • number of logical cpus
  • total memory
  • number of nics

Thanks!

I may get the core of it all started with just a few and it will be VERY easy for folks to send patches to add more.

I would expect it is possible to create facts based on custom criteria,
especially those based on network information, naming conventions or even
other sources (on the system or external).

So having a modular environment to plug in logic into library/setup seems
very useful to me.

Yeah, this is a very good idea.

Currently modules transfer before execution. We’ll probably have all the core ones built into a “setup” module, and could teach the “Runner” code to also transfer a “custom_setup” module if and only if it exists, that the setup module would know to look for. (Or maybe even custom_setup* [all modules starting with that])

I want to avoid a large number of files to move by default, but moving one or two user modules across is not a bad idea at all, and they’d just have to return JSON and could be written in any language too. There would be pretty much zero rules to how you coded them as long as they returned a hash/dictionary.

–Michael