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

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

[Fabian Grünbichler]

to avoid the need to mark every package shipping PVE-related perl code as
activating the explicit trigger. the explicit trigger can still be used for
packages that need to reload the API without shipping a perl module

the explicit trigger activation can be dropped in PVE 9.0 in packages that ship
perl code, without a need for versioned dependencies.

Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
---
Currently, the following packages ship perl modules in /usr/share/perl5/PVE,
but don't activate the explicit trigger:

libpve-apiclient-perl libpve-cluster-perl libpve-notify-perl pve-cluster libpve-u2f-server-perl dab

libpve-cluster-perl is upgraded in lockstep with libpve-cluster-api-perl, which does activate the trigger.

manually tested reinstalling `pve-cluster` with and without this patch, seems to work as expected.

are there other paths that might make sense to "watch"?

 debian/triggers | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/triggers b/debian/triggers
index aabe418ef..4e3a2a3d9 100644
--- a/debian/triggers
+++ b/debian/triggers
@@ -1 +1,2 @@
 interest-noawait pve-api-updates
+interest-noawait /usr/share/perl5/PVE
-- 
2.39.5



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

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

[Thomas Lamprecht]

Am 05.11.24 um 12:43 schrieb Fabian Grünbichler:
> to avoid the need to mark every package shipping PVE-related perl code as
> activating the explicit trigger. the explicit trigger can still be used for
> packages that need to reload the API without shipping a perl module
> 
> the explicit trigger activation can be dropped in PVE 9.0 in packages that ship
> perl code, without a need for versioned dependencies.

Not for the HA usecase.

> 
> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
> ---
> Currently, the following packages ship perl modules in /usr/share/perl5/PVE,
> but don't activate the explicit trigger:
> 
> libpve-apiclient-perl libpve-cluster-perl libpve-notify-perl pve-cluster libpve-u2f-server-perl dab

At least for libpve-notify-perl it might be nice to get a trigger so that HA
get's restarted there too, most of the rest it would be rather superfluous for
HA.

> 
> libpve-cluster-perl is upgraded in lockstep with libpve-cluster-api-perl, which does activate the trigger.
> 
> manually tested reinstalling `pve-cluster` with and without this patch, seems to work as expected.
> 
> are there other paths that might make sense to "watch"?
> 
>  debian/triggers | 1 +
>  1 file changed, 1 insertion(+)
> 
>

applied, thanks!

Korrigieren

Schließen

Rechtschreibung

Possible spelling mistake found.

use caseIgnorieren



_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

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

[Fabian Grünbichler]

On November 11, 2024 6:44 pm, Thomas Lamprecht wrote:
> Am 05.11.24 um 12:43 schrieb Fabian Grünbichler:
>> to avoid the need to mark every package shipping PVE-related perl code as
>> activating the explicit trigger. the explicit trigger can still be used for
>> packages that need to reload the API without shipping a perl module
>> 
>> the explicit trigger activation can be dropped in PVE 9.0 in packages that ship
>> perl code, without a need for versioned dependencies.
> 
> Not for the HA usecase.
 
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 :)

>> 
>> Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
>> ---
>> Currently, the following packages ship perl modules in /usr/share/perl5/PVE,
>> but don't activate the explicit trigger:
>> 
>> libpve-apiclient-perl libpve-cluster-perl libpve-notify-perl pve-cluster libpve-u2f-server-perl dab
> 
> At least for libpve-notify-perl it might be nice to get a trigger so that HA
> get's restarted there too, most of the rest it would be rather superfluous for
> HA.

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.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

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

[Thomas Lamprecht]

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.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

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

[Fabian Grünbichler]

> Thomas Lamprecht <t.lamprecht@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