Am 27.02.25 um 16:11 schrieb Fabian Grünbichler: >> Fiona Ebner <f.eb...@proxmox.com> hat am 27.02.2025 16:00 CET geschrieben: >> Am 27.02.25 um 15:52 schrieb Fabian Grünbichler: >>> we could make it detectable by including a timestamp? that way, if using >>> stale information is (not) okay, that decision can be made by the >>> consumer of the information, instead of only allowing either variant? >> >> If it's broadcast only once then the timestamp doesn't help much? Or do >> you mean also keeping track/checking when the node last joined the >> quorum to decide? > > no, I meant broadcast it regularly (e.g., one could refresh and rebroadcast > the information based on some file being changed that is always touched by > dpkg/apt on package operations? or just on a schedule that is less frequent > than "every pvestatd cycle") *and* include the timestamp of the last update > so the other side can act on that..
For version specific information we could also hook into apt/dpkg to trigger such an update on-demand plus with a low frequency (say hourly) periodically, and that could be optimized to just write a newer timestamp if the info stayed the same, the simplest way to do that would probably be having to keys, one for the timestamp and one for the version info. FWIW, I'd also slightly favor in having the information but with a timestamp, with periodic updates and a node-last-online timestamp one could determine if the information is stale for sure if the node is offline or if the info is older than $now minus the period length. That said, I did not evaluate that with all potential use cases in mind, so not a hard recommendation to go that way. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
