On Mon, Jun 23, 2014 at 4:42 PM, Eric Sorenson <[email protected] > wrote:
> On Thursday, April 3, 2014 10:32:04 AM UTC-7, Adrien Thebo wrote: >> >> On Wed, Apr 2, 2014 at 12:33 AM, Erik Dalén wrote: >> >> I'm also wondering now when it is time to actually start writing it if >>> you have any thoughts about some overall structure to it before it turns >>> into a mess? For example ohai has some large top level hashes with a bunch >>> of facts under each of them: languages, network, filesystem, counters, >>> kernel & etc. We don't have to copy that structure exactly of course, but >>> it seems to make sense, and apart from kernel none of those names clash >>> with old facts. >>> >> >> Looking at ohai output on a centos6 vm, ( >> https://gist.github.com/ahpook/4f8a5782de64fa2b0768 ) there are number >> of nested fact structures that facter has some overlap with: >> > > * network, w/ an interfaces hash and 'default_interface' / > 'default_gateway' keys > * kernel, with a few keys for uname info > * memory, looks like its parsed straight from /proc/meminfo > * virtualization > * cpu, w/ /proc/cpuinfo > * keys, containing the hosts ssh pub keys > > and I would be all for just mimicing the substructure of those unless > there's some strong reason not to. Introducing the structured facts at new > non-colliding names would be a way to get them in during 2.x feature > releases without harming backwards compatibility. > I'm plus one on Erik/Eric's comments above also. So assuming we go with the non-colliding top-level names: * network * filesystem * virtualization * memory * cpu * keys What should we do with the colliding ones? The two that come to mind are: * kernel * uptime In the gist above, ohai doesn't have a structured 'uptime' - it has a top-level 'uptime' and 'uptime_seconds' (and then it also has a top-level 'idletime' and 'idletime_seconds'). Seems like it would be nice to structure that information though. We could go with 'uptime_hash' but that seems awkward, and then in a year or two we'll be explaining why some facts have "_hash" in their name :> Alternately we could go with something generic like 'time' but that might be go generic as to be meaningless. And then 'kernel' (which is structured in the gist above). We could go with 'os' as a top-level structured name ('os' in the gist above is a flat fact, but that's not a fact name in facter currently). Or ... Comments? Naming is hard :) Kylo Or there may be natural-enough names like, e.g. these might just be intuitive enough without colliding: * virtualization * processors or cpu But my creativity is failing me for, say, "kernel" and "uptime". Naming is hard ;) Comments? Kylo -- 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/CALsUZFHP1aHfy2RkAb7yvU1J9ZRygaMa42AegVQ0eYk5h11y%2Bw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
