[pbs-devel] [PATCH proxmox-backup 1/3] fix #4315: jobs: modify GroupFilter so include/exclude is tracked

[Wolfgang Bumiller]

On Wed, Oct 25, 2023 at 05:45:11PM +0200, Thomas Lamprecht wrote:
> Am 25/10/2023 um 17:07 schrieb Philipp Hufnagl:
> > 
> > 
> > On 10/25/23 15:33, Thomas Lamprecht wrote:
> >> Am 24/10/2023 um 16:32 schrieb Philipp Hufnagl:
> >>>
> >>>
> >>> On 10/24/23 12:43, Lukas Wagner wrote:
> >>>
> >>>> Do you have any examples in mind that would be more difficult to
> >>>> represent?
> >>>
> >>> I would like to include all vms from 10 to to 30, but not 17,18 and 20.
> >>>
> >>
> >> How is that more difficult?
> >>
> >> IMO Lukas proposal seems reasonable, a deterministic remove matches from
> >> excludes fromm all matches from includes seems easier to understand,
> >> from top of my head.
> > 
> > You would have to do something like
> > 
> > include 10-30
> > exclude 17
> > exclude 18
> > exclude 20
> > 
> > instead of
> > 
> > include 10-30
> > exclude 17-20
> > include 19
> > 
> > While the first is easier to understand, the 2nd one allows (in my
> > opinion) to build a cleaner solution for complex filtering.
> 
> Easier to understand is *much* cleaner though, any admin that changes
> a simple include/exclude filter manually, e.g., reversing the order,
> has no idea that the end result is completely different.

I disagree that either of them is actually easier, and we already have
order dependent include/exclude behavior in `.pxarexcludes` and on the
CLI via `--exclude` when creating a backup with proxmox-backup-client.

Also, `.gitignore` also works like this, you have exclude and includes
in order, the last match wins.
This makes it much easier to say things like "exclude 1-100 except 50",
which, to me, seems like the most complex case you would want anyway?

Which you find easier probably depends on what you see more often, but
for consistency's sake it may make more sense to stick to what we
already have?