Re: [pbs-devel] [PATCH v5 proxmox 2/8] pbs api types: add option to set GC chunk cleanup atime cutoff

From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Christian Ebner <c.ebner@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH v5 proxmox 2/8] pbs api types: add option to set GC chunk cleanup atime cutoff
Date: Wed, 19 Mar 2025 10:13:38 +0100	[thread overview]
Message-ID: <8b2ca54b-2041-4e1b-b2d3-71c89a984542@proxmox.com> (raw)
In-Reply-To: <4ff622ce-23ff-4b9a-9336-7d8aa4c7c6f2@proxmox.com>

Am 19.03.25 um 10:08 schrieb Christian Ebner:
> On 3/19/25 10:01, Thomas Lamprecht wrote:
>> Am 19.03.25 um 09:48 schrieb Christian Ebner:
>>> Given this I did check also the output in the docs, which however shows
>>> the very unintuitive integer rage and default value.
>>>
>>> So given that, maybe it would be better to switch from an integer schema
>>> to a string schema and parse the values as HumanTime?
>>> Similar to what is done for the GC schedule.
>>
>> That might indeed have some benefits UX wise, albeit I'm not 100% sure how
>> good this is in  the web UI, or is there a pre-existing use case for
>> HumanTime in the UI and thus ideally have already a nice validator there to
>> provide quicker feedback to users if they enter something bogus.
> 
> I think this could be done in the schema validation function, but have 
> to take a closer look.

Sure, but that would mean a roundtrip to the backend is required, having
a frontend validation provides less latency w.r.t. feedback if a value
is fine.

Albeit we do not have a good one for calendar events, so this might be
a bit of a high bar to ask for now. FWIW, this will get "solved" by a
rust based UI where we can reuse the exact same types and validators also
for the frontend without any (developer) overhead (we could also compile
just the validators we want now as WASM and use that in the ExtJS UI, but
that not sure if that's worth the hassle).

> 
>> As the GC schedule is a calendar event, i.e. time instants not really time
>> durations like HumanTime is, e.g. `daily` or `hourly`, which calendar event
>> support would not make that much sense here.
> 
> Yes, these would definitely need to be excluded.

I think we mean the same, but just to be sure: It should not need to be
excluded as those are just two different types, as mentioned one is for
instants on a calendar and the other is for durations.

_______________________________________________
pbs-devel mailing list
pbs-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel