[RFC firewall 0/3] add triggers for PVE perl code updates

[RFC firewall 0/3] add triggers for PVE perl code updates

[Fiona Ebner]

Similar to the services shipped by pve-manager, the firewall service
should also be reloaded when Perl packages like libpve-common-perl or
libpve-network-perl are updated. There are false positives too, like
libpve-storage-perl, and avoiding theses would require a new trigger
name specifically for firewall and activating that new trigger in all
its dependencies. But maybe that one is the better way? Happy to hear
opinions :)

A path-based interest is chosen following the same rationale as
pve-manager commit 27d1db3a ("triggers: add path-based trigger
interest").

Note that this is not prompted by an actual issue I encountered, but
I did notice it when the firewall was still running with some manually
added logging in Daemon.pm even after reinstalling pve-common. I was
surprised and I felt like it's worth discussing whether we want any
triggers for the firewall service.

pve-firewall:

Fiona Ebner (3):
  d/postinst: handled triggers by reloading service
  d/pve-firewall.triggers: add interest in PVE perl code updates
  d/pve-firewall.triggers: drop superfluous pve-api-updates activation

 debian/postinst              | 4 ++++
 debian/pve-firewall.triggers | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)


Summary over all repositories:
  2 files changed, 5 insertions(+), 1 deletions(-)

-- 
Generated by git-murpp 0.5.0

[RFC firewall 1/3] d/postinst: handled triggers by reloading service

[Fiona Ebner]

In preparation for commit "d/pve-firewall.triggers: add interest in
PVE perl code updates".

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---
 debian/postinst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/debian/postinst b/debian/postinst
index 8cdb468..edeed42 100644
--- a/debian/postinst
+++ b/debian/postinst
@@ -16,6 +16,10 @@ case "$1" in
 	deb-systemd-invoke $_dh_action pve-firewall.service >/dev/null || true
     ;;
 
+    triggered)
+        deb-systemd-invoke try-reload-or-restart pve-firewall.service >/dev/null || true
+    ;;
+
     abort-upgrade|abort-remove|abort-deconfigure)
     ;;
 
-- 
2.47.3

[RFC firewall 2/3] d/pve-firewall.triggers: add interest in PVE perl code updates

[Fiona Ebner]

Similar to the services shipped by pve-manager, the firewall service
should also be reloaded when Perl packages like libpve-common-perl or
libpve-network-perl are updated. There are false positives too, like
libpve-storage-perl, and avoiding theses would require a new trigger
name specifically for firewall and activating that new trigger in all
its dependencies.

A path-based interest is chosen following the same rationale as
pve-manager commit 27d1db3a ("triggers: add path-based trigger
interest").

Re-using pve-api-updates would be possible, but not quite fitting and
also would require a lintian override since the package is also
activating that trigger. If using a name-based trigger, then it should
rather be a dedicated one.

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
---

Maybe the approach with an explicit trigger name is better here?

 debian/pve-firewall.triggers | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/pve-firewall.triggers b/debian/pve-firewall.triggers
index 59dd688..ea8e9e2 100644
--- a/debian/pve-firewall.triggers
+++ b/debian/pve-firewall.triggers
@@ -1 +1,2 @@
 activate-noawait pve-api-updates
+interest-noawait /usr/share/perl5/PVE
-- 
2.47.3

[RFC firewall 3/3] d/pve-firewall.triggers: drop superfluous pve-api-updates activation

[Fiona Ebner]

pve-manager commit 27d1db3a ("triggers: add path-based trigger
interest") added a path-based interest and states:

> 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: Fiona Ebner <f.ebner@proxmox.com>
---

If we expect the package to stop shipping Perl code at some point,
maybe it is better to just keep it?

 debian/pve-firewall.triggers | 1 -
 1 file changed, 1 deletion(-)

diff --git a/debian/pve-firewall.triggers b/debian/pve-firewall.triggers
index ea8e9e2..4294b34 100644
--- a/debian/pve-firewall.triggers
+++ b/debian/pve-firewall.triggers
@@ -1,2 +1 @@
-activate-noawait pve-api-updates
 interest-noawait /usr/share/perl5/PVE
-- 
2.47.3