On Thu, Aug 26, 2010 at 3:39 PM, R.I.Pienaar <[email protected]> wrote: > > ----- "Luke Kanies" <[email protected]> wrote: > >> > >> > I think this restricts the utility of Facter to a point where it may >> > as well simply be part of Puppet. >> >> I think it's exactly the opposite - because it doesn't include any of >> the features that Puppet wants, it's more generically useful.
Damnit. I can't work out whether you've convinced me or not with that. :) >> >> But I get what you're saying, and I'm not opposed to an operational >> mode in Facter that does this. It just doesn't fit enough with how we >> need to use it that it's worth us spending a lot of time on it. It >> should be straightforward to add, though, right? > > > I quite like that facter is a reusable little library - obviously I use it > with mcollective - but I've even deployed it on cfengine sites and used it to > build quick and dirty inventories with. > > The fact that its small, doesnt bring lots of bloat, doesnt take lots of > resources - at least when its not running - these are all awesome aspects and > doesnt mean we cant use it in larger inventory systems but would rather see > those as optional with different ways of transporting the facts to them After thinking this through for a while, I've realized I really don't have a strong opinion as to which layer/component a persistent store should live in, but just really want debugging to be simple. There is definitely a huge advantage for Facter being simple. I wasn't suggesting that a local persistent store would be on by default, but keep flipping back and forth as to where I think it should live. -- nigel -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
