On Tue, Aug 22, 2023 at 11:17:14AM +0200, Fiona Ebner wrote: > Am 21.08.23 um 15:44 schrieb Lukas Wagner: > > Open questions: > > - not sure what a good expiration time for cached entries is. For > > now I picked 30s, but there was not much thought behind that value. > > > > If operations affecting the values like allocation, resize, etc. would > invalidate the cache, I think we could go for a bit more. But if they > don't, the limit can't be too high IMHO. Otherwise, users will wonder > why the usage on the storage doesn't change after their action. > > And would it make sense to have the cache be opt-in? So that only > pvestatd would use it, but standalone API/CLI calls always get current > values? If there is invalidation like mentioned above, that might not be > needed, but otherwise, I'm a bit afraid that handing out (slightly) > outdated values might trip up some automated scripts doing batch work or > something.
CLI tools should definitely have an explicit cache-opt-out switch (or - for some of them - that might even be a sensible default, but ideally you'd also have a way to quickly check for temporary discrepancies between the cache and the current value via the CLI). But I the API should stick to to using the cache by default. (But can of course also have an explicit cache-opt-out or force-cache-refresh option - whichever makes more sense.) That's kind of the whole idea, to not have 5 daemons query the exact same data simultaneously ;-) _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
