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 7ABBE9B230 for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:49:58 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 54EE116772 for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:49:28 +0100 (CET) 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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:49:27 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 82B94433A2 for <pve-devel@lists.proxmox.com>; Mon, 20 Nov 2023 10:49:27 +0100 (CET) Message-ID: <be0c1f12-c392-47cd-8213-e3f83355cd3e@proxmox.com> Date: Mon, 20 Nov 2023 10:49:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: de-AT, en-US To: Dominik Csapak <d.csapak@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20231114130000.565122-1-l.wagner@proxmox.com> <80bd1a0b-6435-482a-bca0-3ee49e7dd1ce@proxmox.com> <69565345-fbc5-478c-a2cf-4c83b5f1bba1@proxmox.com> <987d0f8d-26c1-4c56-ad3f-f2e34c45e678@proxmox.com> From: Lukas Wagner <l.wagner@proxmox.com> In-Reply-To: <987d0f8d-26c1-4c56-ad3f-f2e34c45e678@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.009 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 T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH v2 many 00/52] revamp notifications; smtp endpoints; system mail X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Mon, 20 Nov 2023 09:49:58 -0000 On 11/20/23 10:11, Dominik Csapak wrote: >> A 'match-type' rule would simplify this by simply allowing one to list >> all notification types on wants to match, eg. >> >> matcher: test3 >> match-type vzdump,replication >> >> >> For this 'specialized' match-rule we could easily add a list of known >> values in a drop-down (first hardcoded in the UI, later retrieved via >> an API call) > > maybe having it more generic and making it 'match-list' with a property > and multiple > values would make more sense? altough that would be very similar to allow > nesting of modes e.g. > > mode all > - mode any > - match-field exact:type=foo > - match-field exact:type=foo > - match-severity:... > > would that be feasible to do (probably not in the short term)? > This could easily be implemented as an extension to the 'match-field' rule by adding another mode: match-field list:type=vzdump,replication Maybe 'list' is not the best name for this mode, but you get the idea. Theoretically, we could have this 'generic' approach in the backend, while also adding a 'match-type' 'virtual' node type (using the generic list-matching) in the UI to make things obvious for the user. The 'composable' nesting of nodes would be added independently of this. The implementation in proxmox_notify will be pretty easy, but the UI/API handler part could be a bit tricky - since we have to add/modify/delete multiple matchers 'atomically' in a single transaction (when pressing OK in the GUI). So either a 'match-type' or the list-extension would definitely be nice until we have that - and also afterwards, because you can skip nested nodes in some cases if you have this feature. -- - Lukas