so that API paths that raise an exception while holding a CFS lock
properly propagate that exception to the client, instead of the
stringified version with added noise about locks added to the front.
Signed-off-by: Fabian Grünbichler <f.gruenbich...@proxmox.com>
---
Notes:
there seems to be nothing that matches on the prefix added by cfs_lock.
some API calls in pve-access-control, pve-storage and Replication would now
benefit from raising (parameter) exceptions instead of a plain death while
having a config file locked (mainly checking for duplicates when adding
entries)
data/PVE/Cluster.pm | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/data/PVE/Cluster.pm b/data/PVE/Cluster.pm
index b4de989..cce681b 100644
--- a/data/PVE/Cluster.pm
+++ b/data/PVE/Cluster.pm
@@ -609,7 +609,13 @@ my $cfs_lock = sub {
alarm($prev_alarm);
if ($err) {
- $@ = "error with cfs lock '$lockid': $err";
+ if (ref($err) eq 'PVE::Exception') {
+ # re-raise defined exceptions
+ $@ = $err;
+ } else {
+ # add lock info for plain errors
+ $@ = "error with cfs lock '$lockid': $err";
+ }
return undef;
}
--
2.20.1
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
