From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E49BD1FF13A for ; Wed, 01 Apr 2026 13:46:12 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 11A8C18F8E; Wed, 1 Apr 2026 13:46:40 +0200 (CEST) Message-ID: <74884b81-1438-4487-956c-f23982d820af@proxmox.com> Date: Wed, 1 Apr 2026 13:46:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH manager] api: backup: add return schema for backup jobs To: Lukas Wagner , pve-devel@lists.proxmox.com References: <20260327152015.394455-1-l.wagner@proxmox.com> <85e49408-7899-49b4-82d8-8aad320a9c04@proxmox.com> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1775043938337 X-SPAM-LEVEL: Spam detection results: 0 AWL -1.501 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 1 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 1 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 1 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: VTRVZSAQI5DLGJ64QPFVOLRFSDRD3QI4 X-Message-ID-Hash: VTRVZSAQI5DLGJ64QPFVOLRFSDRD3QI4 X-MailFrom: t.lamprecht@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Am 01.04.26 um 12:00 schrieb Lukas Wagner: >>> +my $backup_job_return_schema = PVE::VZDump::Common::json_config_properties({ >>> + id => get_standard_option('pve-backup-jobid'), >>> + schedule => { >>> + description => "Backup schedule. The format is a subset of `systemd` calendar events.", >>> + type => 'string', >>> + format => 'pve-calendar-event', >>> + maxLength => 128, >>> + optional => 1, >>> + }, >>> + starttime => { >>> + type => 'string', >>> + description => "Job Start time.", >>> + pattern => '\d{1,2}:\d{1,2}', >>> + typetext => 'HH:MM', >>> + optional => 1, >>> + }, >>> + dow => { >>> + type => 'string', >>> + format => 'pve-day-of-week-list', >>> + optional => 1, >>> + description => "Day of week selection.", >>> + requires => 'starttime', >>> + default => ALL_DAYS, >>> + }, >> I'd apply this with the following on-top or squashed-in, ack? Hmm, we might actually just drop above two legacy fields here (soon). As for the modern jobs.cfg (based on PVE::Job::Registry in pve-common) we do not have them anymore at all, AFAICT, so those are only possible for the old CRON based vzdump.cron, and those we map in the API endpoint via: my $data = cfs_read_file('vzdump.cron'); my $res = $data->{jobs} || []; foreach my $job (@$res) { $job->{schedule} = $convert_to_schedule->($job); } The convert_to_schedule method keeps the current starttime/dow params, but the API contract now is basically, dow and starttime might be there, if a vzdum.cron still exists and nobody updated/added/removed any backup job since a while, as that would convert them to the modern jobs.cfg, having keept the old vzdump.cron only around to ensure that PVE nodes with older pve-mananger in a cluster still handle pre-existing backup old-style jobs correctly. But that was introduced mostly in commit 305921b1a ("api/backup: handle new vzdump jobs") [0] back in PVE 7.1 days, so we probably can just drop that, and we probably also do not need to wait until a next major release, as vzdum.cron cannot really be used anymore in practice (besides manual editing, which I do not care that much for). And for the backup job API response it's rather a clear cut, schedule is _always_ present, starttime/dow basically never, and all (API) clients need to cope with schedule since PVE 7.1, so dropping it from the return schema and (not a must, but nicer) deleting them from the response should be fine. I know, it's a bit annoying to have those legacy ghosts in scope for such patches, but it has some value to clean a few of them up when they resurface, especially when doing this with the end goal of encoding such types in rust in pve-api-types for use with PDM, as all legacy cruft we can safely shave off can make our life simpler. [0]: https://git.proxmox.com/?p=pve-manager.git;a=commitdiff;h=305921b1a