From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id CC99E1FF0AF for ; Thu, 22 Oct 2026 10:19:20 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 59012215CF; Thu, 22 Oct 2026 10:19:16 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 22 Oct 2026 10:19:10 +0200 Message-Id: Subject: Re: [PATCH proxmox v4 15/39] notify: migrate PBS's and PVE's default matcher to expression syntax From: =?utf-8?q?Michael_K=C3=B6ppl?= To: "Lukas Wagner" , =?utf-8?q?Michael_K=C3=B6ppl?= , , X-Mailer: aerc 0.22.0 References: <20261012131413.314088-1-l.wagner@proxmox.com> <20261012131413.314088-16-l.wagner@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1792657150669 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.233 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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: I4SJNSFB5GU7CLBQVJ4ZAJREUPFQV5U2 X-Message-ID-Hash: I4SJNSFB5GU7CLBQVJ4ZAJREUPFQV5U2 X-MailFrom: m.koeppl@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: On Thu Oct 22, 2026 at 9:35 AM CEST, Lukas Wagner wrote: > On Wed Oct 21, 2026 at 4:39 PM CEST, Michael K=C3=B6ppl wrote: >> On Mon Oct 12, 2026 at 3:13 PM CEST, Lukas Wagner wrote: >> >> [snip] >> >>> + use proxmox_match_expression::{not, any_of, all_of}; >>> + >>> + let expression =3D any_of![ >>> + not!( >>> + FieldMatcher::Exact { >>> + field: "type".into(), >>> + values: vec!["prune".into()], >>> + }.into() >>> + ), >>> + all_of![ >>> + FieldMatcher::Exact { >>> + field: "type".into(), >>> + values: vec!["prune".into()], >>> + }.into(), >>> + SeverityMatcher { >>> + severities: vec![Severity::Error, Severity::Wa= rning, Severity::Notice], >> >> This is more of a question than actual feedback, I think, but how likely >> is it that additional severity levels could be added in the future? > > Not impossible (e.g. maybe we'd want to have 'critical' at one point, to > differentiate 'hey, your cluster is on fire' from a mere failed backup), > but also not something that is on the immediate horizon, as far as I'm > concerned. > >> Because the old default matcher was >> not(type =3D=3D prune AND severity =3D=3D info), whereas this specifical= ly >> matches a list of severities that would need to be extended to remain >> equivalent, no? >> >> In any case, couldn't this simply be >> >> ``` >> let expression =3D not!(all_of![ >> FieldMatcher::Exact { >> field: "type".into(), >> values: vec!["prune".into()], >> }.into(), >> SeverityMatcher { >> severities: vec![Severity::Info], >> }.into(), >> ]); >> ``` >> >> to be equivalent to the old one? Or is there a reason this is not the >> case? > > The main reason why I changed the representation was that the old one > was really quite difficult to understand; I've asked multiple people in > a poll and they all preferred representation used in this patch. > Yeah, true, I forgot about that. As I recall, I was even one of the people who found the new representation more intuitive (and looking at it again now, I still think so). > I don't view the default matcher to be set in stone anyway, so having to > change it if we add more severity levels does not really concern me. > > A patch series I'm currently working on moves the definition to the > application code, which makes it also easier and quicker to adapt in the > future. Sounds good! Sorry for the noise then :)