Hey, good points - state retention at whatever granular level would be a good general purpose tool to have. If it's built in a pervasive fashion (i.e., any provider might use the cache for whetever it deems appropriate), it gains added visibility and becomes more opaque to the user - which is a good thing, and addresses one of the major concerns I'm having with this. The other being that it needs to be tunable for the user in some fashion.
I have no qualms about disk I/O - after all, the user can choose whatever block backend they want. Users who depend on low latency or need to save IOPS can employ a tmpfs, for example. Cheers, Felix On 12/17/2014 12:56 AM, Trevor Vaughan wrote: > I'm happy with catalog lifetime. > > I'm really not happy with doing anything that involves disk I/O. > > This would be key to getting providers to be able to save state in a > non-hacky way as well. > > Trevor > > On Tue, Dec 16, 2014 at 6:45 PM, Michael Smith > <michael.sm...@puppetlabs.com <mailto:michael.sm...@puppetlabs.com>> > wrote: > > I don't like any of the ideas I raised, but this will take some > digging. We need to determine what life-time the cache should > have, and what interface. I'm leaning towards either a cached read > API in the FileSystem utilities, or a cache tied to the catalog > lifetime. > -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/5490D048.7020702%40Alumni.TU-Berlin.de. For more options, visit https://groups.google.com/d/optout.
