Facts for Specific OS which are not prefixed by an OS prefix etc

[Damon Atkins]

Hi, I am seeing a direction which will need to puppet being a bit of a mess. i.e. Linux is the only OS.

Facts need to be prefixed by their OS.   e.g. win_ or unix_  If unix specific then lnx_ aix_ sol_ hpux_ etc
If the fact is not available or common to most OS it should be prefex... If Puppet wants to be king of all OS it needs to be design for all os include module name and facts.

e.g. http://docs.puppetlabs.com/facter/1.7/core_facts.html

blockdevice_{devicename}_vendor

Returns the vendor name of block devices attached to the system.

Resolution: Parse the contents of /sys/block/{device}/device/vendor to retrieve the vendor for a device.

Caveats: Only supports Linux 2.6+ at this time, due to the reliance on sysfs.

---
If the aim of this is to support all OS, and puppet labs is just starting with Linux that is fine. What are block devices on other OS and does it represent the same thing. Do we need to know if they are tape or disk or serial port etc.  Can we turn this off, on systems with hundreds of block devices?

Other wise if this is linux specific  I would suggest this should be in a module called linux_facts

Servers can have hundreds of devices, and a 3 facts per device seems the wrong approach. A hash (or jason/yaml) would be better solution. This the functions required to look through the hash...

For example the following should exist on most OS, but should be group together instead of a fact per interface.

1. ipaddress6  (should not exist or be an array)
   
2. ipaddress6_{NETWORK INTERFACE}
3. network_{NETWORK INTERFACE}

We talk about removing data from modules... However in order to write generic modules facts need to be generic.
Writing code like if $::network_eth0 = x.x.x.x.
if $::network_eth1 = x.x.x.x.
I have no way to know the the number of interfaces and their names.....

Facts need to come with functions to make them useful.
facts_regex2array(/^ipaddress6_.*/)  would help with the above. But facts need to support strings, hash and arrays.
e.g.
networkif_name=['eth0','eth1','eth2']
networkif_ip4=[192.168.0.1,192.168.1.1,192.168.2.1]
or in a hash (i like the above as less data to transfer then if it was a hash)

If puppet wants to be all things to all OS, then facts and modules need a prefix for the OS when the particular fact or module will only work on a particular OS.  Modules which do not follow this guide line should not be accepted by the forge if puppet wants to support many many OS.

What are other peoples thoughts.

Cheers

[Felix Frank]

Hi Damon,

you raise a slew of points, I'll try to cover as many as I can.

On 02/01/2014 06:59 AM, Damon Atkins wrote:
> Hi, I am seeing a direction which will need to puppet being a bit of a
> mess. i.e. Linux is the only OS.

I don't agree, but yes, the common Linux distributions arguably have the
best support at this time.

> Facts need to be prefixed by their OS. e.g. win_ or unix_ If unix
> specific then lnx_ aix_ sol_ hpux_ etc
> If the fact is not available or common to most OS it should be
> prefex... If Puppet wants to be king of all OS it needs to be design
> for all os include module name and facts.

Generally, I think it is important to remember that there is at least
two kinds of facts:
1. facts about hardware, OS independent (e.g. processorcount)
2. facts about the OS
Also, there is a gray area where the OS has a specific way to address
certain pieces of hardware, such as ethX on *NIX vs. whatever
nomenclature Windows uses.

> e.g. http://docs.puppetlabs.com/facter/1.7/core_facts.html
>
>
> blockdevice_{devicename}_vendor
>
> Returns the vendor name of block devices attached to the system.
>

> *Resolution:* Parse the contents of

> |/sys/block/{device}/device/vendor| to retrieve the vendor for a device.
>

> *Caveats: *Only supports Linux 2.6+ at this time, due to the reliance
> on sysfs.
>

What is the exact argument this example is supposed to support?

> ---
> If the aim of this is to support all OS, and puppet labs is just
> starting with Linux that is fine. What are block devices on other OS
> and does it represent the same thing. Do we need to know if they are
> tape or disk or serial port etc. Can we turn this off, on systems
> with hundreds of block devices?

Should we? Perhaps a means to configure facter to suppress certain
collections might be sensible.

About representing things that OSs handle differently, I believe it is
preferable to use a naming scheme that is consistent throughout agent
OSes. In some cases that may mean that there are *NIXisms in the fact
names for historic reasons. Such facts could be deprecated in favor of
neutrally named ones over time.

> Other wise if this is linux specific I would suggest this should be
> in a module called linux_facts

Fact namespacing? I have mixed feelings about that, and tend to think
this may create unnecessary problems, and fix what I conceive to be a
non-issue.

> Servers can have hundreds of devices, and a 3 facts per device seems
> the wrong approach. A hash (or jason/yaml) would be better solution.
> This the functions required to look through the hash...

The good news is that (as has been discussed on this list), facter 2
shall indeed support structured data.

Seeing as facter 1 does not, discussing the shortcomings of the current
workarounds will serve little purpose, I'm afraid.

<snip>

> If puppet wants to be all things to all OS, then facts and modules
> need a prefix for the OS when the particular fact or module will only
> work on a particular OS. Modules which do not follow this guide line
> should not be accepted by the forge if puppet wants to support many
> many OS.

I don't agree. There have always been facts that are just not available
in certain environments. This is natural and manifests/templates should
be prepared to deal with their absence if applicable.

Again, namespacing will likely raise other issues (e.g., how to prefix
facts that are limited to, say, Linux and FreeBSD).

Regards,
Felix

[Damon Atkins]

Thanks for the response.