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.

Reply via email to