So, in PUP-3116, I proposed a (very bad) solution for reading /prod/mounts every time a file was opened during a run.
The original goal was to get around cases where the sandbox service had not been properly configured and /proc/mounts grew to a few thousand lines. What I would *love* is a proper top-level queueing mechanism both for global items and for individual resources. Henrik indicated that the use of unbound class variables was causing memory leaks so that's out and he recommended the use of a JSON file on the system that would be used as a temporary cache. While this would work, I'm really not thrilled about having anything that we read thousands of time from disk. I did some tinkering and managed to bind an additional variable set to the catalog (being the only globally persistent thing that I could find) but that's obviously also a Very Bad(tm) solution. So, a couple of questions: 1) Do any of the client internals gurus have a suggestion as to how to do this properly. 2) If there's no way to do it properly, whats the most system-efficient way to do it successfully, albeit improperly. I'm not going to post the catalog shim code unless pressed because I fear being stoned at the next PuppetConf :-D. Thanks, Trevor -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoWGzUtfJW-oz62ByjPGFMye%2BCU8XbT2j3YRtoqgHRY-1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.