Hi, You guys may remember me as the dude at puppet camp who suggested in the facter meeting about having facts return unknown for example, or have a default set of facts. This, oddly to me, seemed to not go over well. Let me explain where I'm coming from and why I think the current state of facter is more or less broken.
In my approach to using puppet and systems administration and programming in general, I've found abstraction a great concept and in fact is probably the primary draw for me towards a product like puppet: no more (or much less!) script maintenance for every stupid little difference between every minor version of every OS anyone has ever brought amongst your network. Facter seems like an absolutely amazing idea that can potentially almost completely abstract the admin from the specifics of the OS. For me, it is not living up to this dream and in fact it seems that the powers that be inside of puppet labs are somewhat fighting this notion. Maybe I'm misreading this or we simply have a difference in opinion in how that could be achieved. Anyways, here's what I envision for facter: 1. The basic attributes of the machine you are interfacing with are always represented, and always in the same way. This means the things which are physically impossible to not have will ALWAYS be listed in facter's facts: things like: architecture, processor type, speed, etc, operating system, release versions, etc. 2. All basic facts and perhaps some extended facts should return unknown if they are not able to be determined: this means there is something wrong with facter. Yes. If facter doesn't know something, then it's an incomplete fact. When writing internal facts, if we can't determine a fact, we list it as 'unknown' because that is in fact the value. This promotes code sanity because you can always expect that there will be a value. This makes coding easier because you know the key will exist, though the value may be unknown. 3. Using facter should mean you don't have to know almost anything about the system at all and can only use the same few facts over and over to always reliably determine the basic information about the system. This in fact seems like it would be the number one goal of facter, which kind of leaves me at a question of what exactly is the point of facter? Only to support puppet? I don't really get it if the point is not total abstraction. Let me give you a solid example of what I'm talking about: -To find out how many physical processors a box has, we use two facts: physicalprocessorcount and for osx our own fact: osx_physicalprocessorcount. -To find out what operating system we're on, we have to use two facts: operatingsystem and lsbdistid because some operating systems are reported differently than others. For example XenServer reports operatingsystem as RedHat and lsbdisid as XenServer. But lsbdistid doesn't exist on mac and so now I'm forced to use both. -To get the architecture of a system I must use architecture and hardwaremodel, since hardwaremodel will spit out something like i686 on centos, but will give you i386 on mac, whereas architecture will give you the i386 for centos but doesn't exist on mac. My point is not to complain about all these things but to try to discuss the direction of facter. I got the impression that the main reason behind not adding a bit of intelligence to the facts in these cases was because of code base size, which again I may be mistaken about. Let me tell you if you made a version of facter that was 100MB and always was consistent and correct, I would install it on everything happily. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
