On Thu, May 24, 2012 at 2:25 PM, Chris Price <ch...@puppetlabs.com> wrote:
> On Wed, May 23, 2012 at 4:01 PM, Jeff Weiss <jeff.we...@puppetlabs.com>wrote: > >> <snip> >> > With Facter as both an executable and a library, it turns out to be really >> hard to be able to guarantee that a value will definitely be returned >> within a certain amount of time *and* if it takes longer than that reliably >> spawn something that will resolve the fact and store it in a cache >> > <snip> > > Jeff--could you elaborate on this a bit more? If Facter is being used as > both an executable and as a library, and that is leading to complications > with the caching implementation, would refactoring to provide a cleaner > separation between CLI and library usage alleviate any of the problems? > > The inter-process reader/writer problem is only one portion. If that's all it were, then, yes, we probably could refactor and make internal caching easier. However, we also have clients of Facter that have explicit performance expectations. For the sake of discussion let's say that performance expectation is that facts must return in less than 2 seconds. We could certainly institute a policy that after, say, 1.5 seconds if the facts haven't resolved then we'll read the cache and return. This leads to tricky edge cases: 1) What happens when the resolution time is always > than policy time? a) how do you ever get the value? b) do you have spawn something that asynchronously updates the cache? c) who does that run as? d) does it actually have permission to write to the cache? e) this is fine for an executable, but is this proper behaviour for a library? 2) Who's responsible for updating the cache? a) if you resolve inside policy time, do you write to the cache? b) what if you're a library and your process user doesn't have write permission? These are all things that are better handled by a Facter daemon. We can specify the cached yaml file access API now and have a Facter daemon easily adhere to them while interactively being able to handle the above cases in a much more reliable manner. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com. To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
