Add expiration time frame for Cached version of resources during List Resources

planglois

I understand the reason why the caching has been implemented in NPM for List ressource.

Please consider having an expiration time frame (customizable) that would automagically send the request to the resource instead of showing old and stale data. If the device is there, there is a reason why we want to list and validate what we are really polling. fine by me if the data is a day or two old, but grabbing data from 3 year back is useless to us. I feel this would be a simple thing to implement as this could be checked daily during database maintenance, and simply add a flag to the ressource list to have it considered as stale/old.

cnorborg

At the very least I'd love to see current interface status.   Lets say that when the SNMP scan was done to generate the "List Resources" was done, lets say Jan 1 2020, interfaces 1, 10 and 20 of 48 total interfaces are "UP".   But you go in now to "List Resources" and it brings up the cached one from Jan 1 2020, it will still say that interfaces 1, 10 and 20 are "UP", even if interfaces 1-15 are now in use and "UP" and interface 20 is "DOWN"

Even though most of "List Resources" remains the same, ie: 48 interfaces, the interface status changes often.    I can see maybe if Orion isn't actively monitoring anything but 1, 10 and 20 that it wouldn't have current status of those interfaces, but even if it is monitoring the interface(s), "List Resources" doesn't reflect this.   ie: I should think it should at the very least say that "Interface 1 and 10" are still up, while interface 20 is down, assuming they're monitored.   But, I should also think that if all the interfaces are monitored by another module, lets say UDT, that any monitored interface from any SW module should reflect the latest status.

Or maybe even having an option to refresh interface status, vs. scanning the device for all changes?   I'd assume that would be significantly quicker than a full scan?