o hai :) Engaging in a little zombie thread resurrection here as I've been thinking about structured facts a lot lately and this thread touched on a big concern without any specific resolution.
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. >> > > I agree that it would be good to have better namespacing in Facter, and > now is the time to start creating these. > > There are a couple of approaches here. > > First off, as part of Facter 2 there is a new way of resolving facts in a > piece-wise manner, called aggregate resolutions ( > https://github.com/puppetlabs/facter/blob/master/lib/facter/core/aggregate.rb). > > This allows a single fact resolution to be built up with multiple blocks > that are evaluated and then combined. This is specifically built for things > like network information where you may have a very deeply nested structure > of interface facts, available networking protocols, and whatnot. Moreover > these facts can be extended by custom facts without having to clobber or > override existing resolution implementations. The docs at > http://docs.puppetlabs.com/facter/2.0/fact_overview.html detail the new > functionality that's available. > > This was my best effort to solve the problem of namespacing and building > up complex structures, but I'm still waiting to see how useful it > ultimately is. Depending on how it's used there may be some modifications > to make aggregate resolutions easier to understand and create. > > The other solution for this problem is to introduce the concept of > namespaces into Facter. This has been discussed in the past and there have > been some implementations created, but nothing has been merged into core. > It is a potential option, and depending on how things go we may implement > this to solved the described problem. > I'm not quite sure what 'namespaces' mean here, could you explain that a little more? I'm +1 for Erik's suggestion above, especially now that I've had an opportunity to play with Ohai a bit more. I think we can adopt the core top-level keys and document the schema for the structures underneath them as "curated" core facts whose implementation can be extended into more OSes over time. (To be clear, I'm not suggesting facter directly enforce the schema, just that we describe it so people know where to use 'keys' vs 'each', and what to expect inside the structures.) 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. --eric0 > -- 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/616e8781-afec-40d7-8aec-ac01c2ec07c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
