public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>,
	Dietmar Maurer <dietmar@proxmox.com>
Subject: Re: [pbs-devel] [RFC proxmox-backup] PruneJobConfig: make "schedule" optional
Date: Thu, 16 Nov 2023 14:58:26 +0100	[thread overview]
Message-ID: <7bdef13f-c705-456c-929c-d87946a13675@proxmox.com> (raw)
In-Reply-To: <20231116131904.2415371-1-dietmar@proxmox.com>

Am 16/11/2023 um 14:19 schrieb Dietmar Maurer:
> The API macro already mark this property as optional:
> 
>   schedule: {
>             schema: PRUNE_SCHEDULE_SCHEMA,
>             optional: true,
>   },
> 
> So the correct representation is Option<String> (not String).
> 
> This is now consistent with other job types.
> ---
> 
> Honestly, I have no idea if it was indented to make schedule non-optional?

The whole mix of behavior is due to originally having only one prune
job per datastore, directly encoded in the datastore config.

There it could be disabled by setting the prune schedule to None, see
the screenshot from 1.x times:

https://pbs.proxmox.com/docs-1/_images/pbs-gui-datastore-prunegc.png

Prune jobs got added to allow users to make better use of namespaces,
as there one might want to have different retention per namespace, and
we tried to stay backward compatible with the existing job from
datastore.cfg, but also use our "modern" disable flag like we added
on various places (IIRC one of my first patches was to add that feature
to PVE backup jobs almost a decade ago...).

> Also, why have prune jobs a disable property, while other jobs types
> do not have it?

Because prune jobs tried to use our modern feature set, which includes
a enable/disable flag so users can easily switch a job of without removing
it as a whole, or delete the job's schedule, which can be a nuisance to
restore again, especially if it was a more complex one.

In other words, sync and verify jobs should gain the disable flag for
feature parity, and to provide a slightly more obvious way to (temporarily)
disable a job without loss of (schedule) information.
 
> Also, update_to_prune_jobs_config() looks wrong now because it remove jobs
> without a schedule. Was this really indendet?

Without looking to closely into it: That seems indeed rather odd and
is likely a bug. I did not check your change to closely (sorry, a bit
overloaded with PVE stuff currently) but did you fix that here too?




  reply	other threads:[~2023-11-16 13:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-16 13:19 Dietmar Maurer
2023-11-16 13:58 ` Thomas Lamprecht [this message]
2023-11-16 14:07   ` Dietmar Maurer

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=7bdef13f-c705-456c-929c-d87946a13675@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=dietmar@proxmox.com \
    --cc=pbs-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