JJ> I've sent this patch 3 times now. I'd like a clear call that you
JJ> WILL integrate the patch, and then I can/will generate the patch and
JJ> the "portable" script and even take on the tedious explaining of a
JJ> deep dark innocuous change as needed.

WH> I'd happily agree to it, if it solves the issues I'm worried about.

JJ> Make a list of issues please so I can respond.

So, after brain storming and discussing things a bit, this is the
results of the thinking:

1) We'll switch happily to a directory based "cache".  Everyone has
   agreed this is a better solution if avoids DB locking issues.

2) But we can't depend on cron.  Thus we need to be able to execute any
   resulting script or rpm invocation from within the agent itself (in
   the background).  This could be:

   - fire once at start up

   - fire it once a day, or via some other default period
   - check the directory stat time against the rpm stat time and only
     regenerate when needed (this, IMHO, is preferred over once/day).

3) Needs to be configurable so that the system can do the "install in
   cron" thing.  Rough config tokens needed: 

   RPMDirectory /path/to/it
   RPMFrequency 1d (or directory to stat?)
   RPMCommand   /path/to/script/or/whathaveyou

4) The default location needs to be in a space we control, such as
   /var/net-snmp/hrmib until the RPM folks or "whoever" are willing to
   make a standard place for it (it's beyond our scope to dictate
   something somewhere else).

5) Because the cache may be old, take a long time to update via the
   script, and launched in the background we can't wait before replying.
   So *if* a query comes in then we'll simply answer from an old cache
   (either from disk or memory).  This isn't ideal, but we're willing to
   live with the damage.  Anytime we go to an on-disk cache instead of
   directly linking to the library we're going to run into this problem
   one way or another.  Perfect data synchronization is lost, but not
   hopefully not horribly so.

Dave has checked in code to do the basic read-and-respond-from-path code
(I haven't read it yet), but not the above needed configuration features
to go with it.  IE, right now since we're not doing either cron or
run-ourselves support, the data table will be blank.

Sound good?
-- 
Wes Hardaker
Please mail all replies to [email protected]

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to