On 19 November 2010 01:54, Nathan <n4th4nr...@gmail.com> wrote: > 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.
For what it's worth in future these things are better sent or CC'd to the dev list. I read the users list sporadically at best so if you want my attention dev would be better. > 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. I don't think anyone is against making > 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. Yes but we need to define what those things are, we've certainly seen some odd corner cases crop up from time to time with unusual systems (eg embedded systems). > 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. This is where we disagree - this migh > 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. Why - the basic Facter structure is kinda hash like, it already has a concept of having a key, returning a spoof value for something doesn't feel right. > 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. There is a bug for deduping that stuff, and again a goal for 2.x > -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. A mac isn't an LSB system it makes no sense. You filed a bug for XenServer, so that'll get fixed at some point. There are two problems here - there is no way facter can keep up with the prevalence of distros out there in a reasonable release cycle. Thus there will be always cases sites have to customize, the goal is to make that easy. > -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. This is to do with the problem of meaning - facts have evolved and not be designed and we do not necessarily have a consistent world view of what a particular fact means. This needs to be fixed for the "core" facts (tbd) and is one of the design goals of 2.0. > 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. No it's because it has grown organically, gets very little attention due to being principally community maintained and it not always being my highest priority. That should have been clear in the bugs Consistency is a goal, I just disagree with your concept of always return a value. Paul -- 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.
