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