Jim Klimov
2025-Feb-23 10:54 UTC
[Nut-upsdev] Should NUT have a way to optionally report last-update timestamps (or equivalent deemed safe)?
Hello all, During an issue discussion I began wondering why we don't report any sort of last-update timestamp that consumers could read and decide whether to process the rest of info, for example (similar to HTTP-304). Then I thought it might be unsafe to expose a server timestamp, or service uptime, generally nowadays (especially with NUT read-only access being anonymous) - so it should be hidden by default and only users who want/need the data can enable their drivers to report it (troubleshooting, development, secure LAN...) - and then there's more specific info we could show, like the age of each reading individually. One of the hardest IT problems then rears its head - namely Naming :) I posted some ideas I've had about this at https://github.com/networkupstools/nut/issues/2810 and invite you to share your thoughts here or there. WDYT? Jim Klimov -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20250223/42d86536/attachment.htm>
Greg Troxel
2025-Feb-23 12:53 UTC
[Nut-upsdev] Should NUT have a way to optionally report last-update timestamps (or equivalent deemed safe)?
My quick reaction is that this is a lot of complexity and we should first be clear on the problem. BLUF: I propose that "is this data valid, ie is the UPS reporting data, vs has it stopped" would solve 99.9% of uses, and that we should demand written designs for reasonable uses beyond that in order to justify anything more. I see "are the nut daemons running" as sysadmin monitoring to be dealt with the same way every other daemon is, and thus not to be worried about. (If they crash, we should fix that, but that's separate.) The point of monitoring a UPS is to have fresh data. If you let someone see the data, I don't see the harm in letting them see that it's not fresh, since that's something that should not happen. System uptime is perhaps another matter, but that's not relevant to "is this data ok". I don't see any real value in a 304 not modified so callers can decide to skip processing. This just isn't that complicated. And not modified is since when, and how do we know? I do processing like this in a client, but it's "send a report if something interesting changed, or if it's been a minute since the last report". For that, I just want "give me a dictionary of values". I think it is important to know if the data is stale. But so far, I only need this coarsely. Consider a UPS that updates once every 2s. I am ok with just getting the most recent reading, but if it's been 60s (or whatever nut's threshold is for comms failure), I'm fine with the data being withdrawn. Or perhaps a data_valid: key normally true that goes to false. I really can't see it being reasonable to want timestamps per reading for readings that come at 5s vs 1s. I guess if somebody wants that we can talk about it, but I'd like to see a written design for how it will be used and why that is reasonable. I increasingly find software too complicated as we have years of adding things, so I tend to not want mechanisms unless there's a good reason and then I want the mechanism to be simple/minimal to increase the changes. All that said, I could see a "data_updated: [unix-epoch]" which is basically the last time we heard data from the device. But I would want to see if adding a validity binary sensor is good enough.