On Wed, May 23, 2012 at 4:02 PM, R.I.Pienaar <r...@devco.net> wrote: > > can you give some more detail on how the cache will be used? If a fact > is found on disk via the rb file and there's nothing in the cache will > it then simply run the slow way? and update the cache? > > Facter itself will not use the cache. If you have an application that needs facts and needs them quickly, you may read the yaml file on disk. An entirely separate process will update the cache. At this first step, the update process is planned to be a cron job, with hope of an actual facter daemon later.
> sounds like there would be various chicken and egg situations with > arranging > for pluginsync to have happened before attempts to build the cache so I > am looking to hear some more details to determine if that might be an > issue. > At this time, we are not proposing Puppet use the external cache from the disk. > > There is a definite need for varying ttl times - totalmemory can have a > long > ttl while something like EC2 facts might have a lower TTL > > Agreed. This first step has an effective TTL of the the period of the cron job. We're saying this is our ideal state, only the first step toward it. > > This method has been proven effective in MCollective. > > I wouldnt go so far as saying that :) generating fact caches via cronjob > or puppet writing out yaml files has been a recurring headache for people > > Tell me more, please. -- 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.
