Re: [PATCH datacenter-manager v2] Add notifications backend

[Thomas Lamprecht <t.lamprecht@proxmox.com>]

On 09/04/2026 14:07, Lukas Wagner wrote:
> This was coordinated with me, I told him that it would be okay to send
> this part early. He can either build on top of this series and include
> more patches (e.g. adding the GUI, notification events, docs, etc.) in
> future versions, or if it makes sense we can also apply certain parts
> early.

I'd strongly recommend to generally send along (basic) integration of
such factoring out work, as else it's basically impossible to review and
see that this can work out without the reviewer having to do the work
themselves. This doesn't have to be a fully fledged out thing for an
initial review, but here some basic notification wouldn't be that much
(and has to be done anyway, as how else was this tested?)

btw. I (and probably others) would also appreciate if such discussion
happens in some shared channel (e.g. zulip).

On 09/04/2026 14:07, Lukas Wagner wrote:
>> this would probably also benefit from checking the config digest.
>>
> Same here, I'm not really sure what the benefit would be here?
> 
> IMO there are a couple cases to consider for concurrent modifications:
>   - somebody modified entity A, we delete B -> should be fine
>   - somebody modified entity A, we delete A -> does not matter, we want
>     to delete it anyways

but we did so with the old config values in mind. The somebody might
have added changed a comment from "test" to "production, don't delete"

The point of digest checks are to ensure an action is executed with
the same information the client saw when making the decision.

>   - we deleted A, somebody else modifies A -> update fails anyways due
>     to the wrong config digest or the entity missing already
>   - both try to delete A -> fails for one of both due to the already
>     deleted entity (HTTP 404)
> 
> Did I miss something?

Another one would be: Somebody deleted A, somebody creates A, we
now delete (another!) A.

Config digest checks are a common thing in most of our stacks for
a reason, they certainly are not the most elaborate/best tool, but
they are simple and protect against any decisions that got wrong due
to out-of-date information. I'd be fine with something better, but
ideally it's some slight variation of the current system, like e.g.
reducing the digest assertion-scope from the whole config to an config
entry (not always useful if there are cross-references in the config),
bigger change can be OK, but naturally needs much more justification
and ensuring that it can be used more than once (ideally everywhere).