From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <l.wagner@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 966CE9C57F
 for <pbs-devel@lists.proxmox.com>; Tue, 24 Oct 2023 12:43:12 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id 77E3A1ED85
 for <pbs-devel@lists.proxmox.com>; Tue, 24 Oct 2023 12:43:12 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pbs-devel@lists.proxmox.com>; Tue, 24 Oct 2023 12:43:11 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 3887144BEC
 for <pbs-devel@lists.proxmox.com>; Tue, 24 Oct 2023 12:43:11 +0200 (CEST)
Message-ID: <d9a94b91-e13a-470e-87c9-a600d7cb9d10@proxmox.com>
Date: Tue, 24 Oct 2023 12:43:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: de-AT, en-US
To: Philipp Hufnagl <p.hufnagl@proxmox.com>,
 Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>
References: <20231023154302.2558918-1-p.hufnagl@proxmox.com>
 <20231023154302.2558918-2-p.hufnagl@proxmox.com>
 <54f6b050-02ce-4443-a3f3-e28ee2b875bd@proxmox.com>
 <fb844e0d-26ad-4a7c-a8e5-5d99c29c7b01@proxmox.com>
From: Lukas Wagner <l.wagner@proxmox.com>
In-Reply-To: <fb844e0d-26ad-4a7c-a8e5-5d99c29c7b01@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.022 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
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pbs-devel] [PATCH proxmox-backup 1/3] fix #4315: jobs: modify
 GroupFilter so include/exclude is tracked
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
 <pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Tue, 24 Oct 2023 10:43:12 -0000



On 10/24/23 11:54, Philipp Hufnagl wrote:
>> I would probably do it this way:
>>
>> no group-filters defined -> everything is included
>> only including filter    -> only groups matching the filter(s) are
>>                              included
>> only excluding filter    -> all groups but the matching ones are
>>                              included
> 
> I am not 100% sure how I feel about including all as a starting point
> for exclusion filter. While I understand the intuitive benefit, it
> also may make the process more error prone, since removing 1 include
> filter may change everything to include all. User might not think of that.
>  >> including and excluding  -> first compute included groups, then subtract
>>                              excluded ones
>>
> I considered this. The reason why I decided for only one list is
> because it enables user to make more sophisticated rules more easily.
> 
> Having 2 lists that get processed after each other can make it much
> harder to filter on a complex setup.

Do you have any examples in mind that would be more difficult to
represent?

If you keep it as it is right now, there should be a way to reorder
match rules in the UI, maybe similar to the boot-order drag'n'drop
thing in PVE.

> 
>> Ideally, this behavior should be
>>    a.) obvious in the GUI
>>    b.) documented in the docs, with a few concrete examples
>>
> I see what I can do about explaining this behaviour better in the GUI
> and how to extend the documentation.
> 
> 

-- 
- Lukas