[pve-devel] applied: [RFC manager] triggers: add path-based trigger interest

Fabian Grünbichler f.gruenbichler at proxmox.com
Tue Nov 12 11:28:12 CET 2024


> Thomas Lamprecht <t.lamprecht at proxmox.com> hat am 12.11.2024 10:52 CET geschrieben:
> 
>  
> Am 12.11.24 um 10:11 schrieb Fabian Grünbichler:
> > the HA case could also switch over to this approach, if we want to
> > reload HA for all PVE perl modules.. if we only want it for a subset,
> > then yes, the/an explicit trigger is better :)
> 
> [...]
>  
> > see above - the question is whether we want an explicit list of packages
> > that trigger HA (and risk that it runs out of sync with the modules the
> > HA actually uses), or whether we want to treat HA like the pve-manager
> > services, and just let it reload on any perl module changes that *could*
> > affect it..
> > 
> > if desired, I can send a similar patch for pve-ha-manager as well.
> 
> Yes, that's an option, but I was wording my reply from yesterday so vague
> by choice (or well, being to lazy to decide so late) to not go in a
> explicit direction, as while it would be nice to have this covered in a
> general fashion, more frequently restarting HA is also something that
> can increase problem frequency. But, tbh., it should not be that much and
> it has to work anyway, so can be fine by me.
> 
> Still needs the trigger from pmxcfs I guess? As IMO we should not depend
> that it will always ship in the same package as some perl code that falls
> under your generic trigger.

do we need a trigger for pmxcfs itself? if it gets updated, it restarts itself anyway, and nothing else directly depends on it? the perl bindings to talk to pmxcfs (PVE::IPCC and PVE::Cluster) are covered by the generic path-based trigger for /usr/share/perl5/PVE , so anything using that to talk to it should just express interest on that path..




More information about the pve-devel mailing list