From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: "Proxmox VE development discussion" <pve-devel@lists.proxmox.com>,
"Fabian Grünbichler" <f.gruenbichler@proxmox.com>,
"Fiona Ebner" <f.ebner@proxmox.com>,
"Aaron Lauterer" <a.lauterer@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager] pvestatd: improve broadcast of node version-info
Date: Tue, 4 Mar 2025 10:06:41 +0100 [thread overview]
Message-ID: <cf1f305c-d953-490d-b785-fdb0dfc271ea@proxmox.com> (raw)
In-Reply-To: <1698073178.1734.1740669062307@webmail.proxmox.com>
Am 27.02.25 um 16:11 schrieb Fabian Grünbichler:
>> Fiona Ebner <f.ebner@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
next prev parent reply other threads:[~2025-03-04 9:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-16 16:30 Aaron Lauterer
2025-01-16 16:35 ` Christian Ebner
2025-01-16 16:38 ` Aaron Lauterer
2025-01-16 16:50 ` Christian Ebner
2025-02-27 14:06 ` Aaron Lauterer
2025-01-17 12:18 ` Fiona Ebner
2025-02-26 16:02 ` Aaron Lauterer
2025-02-27 8:59 ` Fiona Ebner
2025-02-27 14:52 ` Fabian Grünbichler
2025-02-27 15:00 ` Fiona Ebner
2025-02-27 15:11 ` Fabian Grünbichler
2025-03-04 9:06 ` Thomas Lamprecht [this message]
2025-02-27 14:34 ` Aaron Lauterer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cf1f305c-d953-490d-b785-fdb0dfc271ea@proxmox.com \
--to=t.lamprecht@proxmox.com \
--cc=a.lauterer@proxmox.com \
--cc=f.ebner@proxmox.com \
--cc=f.gruenbichler@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal