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 > <[email protected] <mailto:[email protected]>> > 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 [email protected]. 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.
