Am 27.02.25 um 16:11 schrieb Fabian Grünbichler:
>> Fiona Ebner 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 b
> Fiona Ebner hat am 27.02.2025 16:00 CET geschrieben:
>
>
> Am 27.02.25 um 15:52 schrieb Fabian Grünbichler:
> > On February 27, 2025 9:59 am, Fiona Ebner wrote:
> >> Am 26.02.25 um 17:02 schrieb Aaron Lauterer:
> >>>
> >>>
> >>> On 2025-01-17 13:18, Fiona Ebner wrote:
> Am 16.01.25 um
Am 27.02.25 um 15:52 schrieb Fabian Grünbichler:
> On February 27, 2025 9:59 am, Fiona Ebner wrote:
>> Am 26.02.25 um 17:02 schrieb Aaron Lauterer:
>>>
>>>
>>> On 2025-01-17 13:18, Fiona Ebner wrote:
Am 16.01.25 um 17:30 schrieb Aaron Lauterer:
> Until now, the pvestatd did broadcast the
On February 27, 2025 9:59 am, Fiona Ebner wrote:
> Am 26.02.25 um 17:02 schrieb Aaron Lauterer:
>>
>>
>> On 2025-01-17 13:18, Fiona Ebner wrote:
>>> Am 16.01.25 um 17:30 schrieb Aaron Lauterer:
Until now, the pvestatd did broadcast the pve-manager version only once
after startup of th
sent a v2
https://lore.proxmox.com/pve-devel/20250227143356.1089350-1-a.laute...@proxmox.com/T/#u
On 2025-01-16 17:30, Aaron Lauterer wrote:
Until now, the pvestatd did broadcast the pve-manager version only once
after startup of the service. But there are some situations, where the
local pmx
On 2025-01-16 17:50, Christian Ebner wrote:
On 1/16/25 17:38, Aaron Lauterer wrote:
On 2025-01-16 17:35, Christian Ebner wrote:
On 1/16/25 17:30, Aaron Lauterer wrote:
[…]
This will close issue 5894 I guess [0]?
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=5894
Specifically, th
Am 26.02.25 um 17:02 schrieb Aaron Lauterer:
>
>
> On 2025-01-17 13:18, Fiona Ebner wrote:
>> Am 16.01.25 um 17:30 schrieb Aaron Lauterer:
>>> Until now, the pvestatd did broadcast the pve-manager version only once
>>> after startup of the service. But there are some situations, where the
>>> l
On 2025-01-17 13:18, Fiona Ebner wrote:
Am 16.01.25 um 17:30 schrieb Aaron Lauterer:
Until now, the pvestatd did broadcast the pve-manager version only once
after startup of the service. But there are some situations, where the
local pmxcfs (pve-cluster) restarts and loses that information.
Am 16.01.25 um 17:30 schrieb Aaron Lauterer:
> Until now, the pvestatd did broadcast the pve-manager version only once
> after startup of the service. But there are some situations, where the
> local pmxcfs (pve-cluster) restarts and loses that information.
> Basically everytime we restart the pmxc
On 1/16/25 17:30, Aaron Lauterer wrote:
Until now, the pvestatd did broadcast the pve-manager version only once
after startup of the service. But there are some situations, where the
local pmxcfs (pve-cluster) restarts and loses that information.
Basically everytime we restart the pmxcfs without
On 1/16/25 17:38, Aaron Lauterer wrote:
On 2025-01-16 17:35, Christian Ebner wrote:
On 1/16/25 17:30, Aaron Lauterer wrote:
[…]
This will close issue 5894 I guess [0]?
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=5894
Specifically, the 'version-info', yes. Are there other properties
On 2025-01-16 17:35, Christian Ebner wrote:
On 1/16/25 17:30, Aaron Lauterer wrote:
[…]
This will close issue 5894 I guess [0]?
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=5894
Specifically, the 'version-info', yes. Are there other properties too?
Until now, the pvestatd did broadcast the pve-manager version only once
after startup of the service. But there are some situations, where the
local pmxcfs (pve-cluster) restarts and loses that information.
Basically everytime we restart the pmxcfs without restarting pvestatd
too.
For example, on
13 matches
Mail list logo
