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 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/52F3FD9F.5080204%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/groups/opt_out.
