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
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
