From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id E77DEBB42 for ; Fri, 8 Apr 2022 09:40:55 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D7883BB2F for ; Fri, 8 Apr 2022 09:40:25 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id DCA38BB26 for ; Fri, 8 Apr 2022 09:40:24 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B6EAC45986 for ; Fri, 8 Apr 2022 09:40:24 +0200 (CEST) Date: Fri, 08 Apr 2022 09:40:18 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Proxmox VE development discussion References: <20220322073412.30562-1-h.laimer@proxmox.com> <20220322073412.30562-3-h.laimer@proxmox.com> In-Reply-To: <20220322073412.30562-3-h.laimer@proxmox.com> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1649402407.jojfvj3vqv.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.176 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH pve-guest-common 2/3] jobs: move VZDump plugin from pve-manager X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 07:40:55 -0000 On March 22, 2022 8:34 am, Hannes Laimer wrote: > Signed-off-by: Hannes Laimer > --- > src/Makefile | 4 + > src/PVE/Jobs.pm | 282 +++++++++++++++++++++++++++++++++++++++++ > src/PVE/Jobs/VZDump.pm | 87 +++++++++++++ > 3 files changed, 373 insertions(+) > create mode 100644 src/PVE/Jobs.pm > create mode 100644 src/PVE/Jobs/VZDump.pm >=20 > diff --git a/src/Makefile b/src/Makefile > index baa2688..853b562 100644 > --- a/src/Makefile > +++ b/src/Makefile [..] > --- /dev/null > +++ b/src/PVE/Jobs.pm > @@ -0,0 +1,282 @@ > +package PVE::Jobs; > + > +use strict; > +use warnings; > +use JSON; > + > +use PVE::Cluster qw(cfs_read_file cfs_lock_file); > +use PVE::Jobs::Plugin; > +use PVE::Jobs::VZDump; > +use PVE::Tools; > + > +PVE::Jobs::VZDump->register(); > +PVE::Jobs::Plugin->init(); so replication would also need to move here when it gets converted to a=20 regular job instead of being called directly by pvescheduler currently those get called via PVE::API2::Replication->run_jobs(), which=20 lives in pve-manager.. > + > +my $state_dir =3D "/var/lib/pve-manager/jobs"; > +my $lock_dir =3D "/var/lock/pve-manager"; any thoughts about migrating these? if not possible, some rationale for=20 why they have to stay until XXX would be good :) > + > +my $get_state_file =3D sub { > + my ($jobid, $type) =3D @_; > + return "$state_dir/$type-$jobid.json"; > +}; > + [..] > diff --git a/src/PVE/Jobs/VZDump.pm b/src/PVE/Jobs/VZDump.pm > new file mode 100644 > index 0000000..44fe33d > --- /dev/null > +++ b/src/PVE/Jobs/VZDump.pm > @@ -0,0 +1,87 @@ > +package PVE::Jobs::VZDump; > + > +use strict; > +use warnings; > + > +use PVE::INotify; > +use PVE::VZDump::Common; > +use PVE::API2::VZDump; and this (like PVE::API2::Replication mentioned above) lives in=20 pve-manager as well and in turn calls other code that also lives in=20 pve-manager, mainly PVE::VZDump -> PVE::VZDump::QemuServer (qemu-server, which is above pve-guest-common=20 in the dep tree) -> PVE::VZDump::LXC (pve-container, same problem) -> PVE::HA::Config & PVE::HA::Env::PVE2 (already involved in a cycle=20 with pve-container / qemu-server, that would just need some look whether=20 it makes stuff worse or not) -> PVE::VZDump::Common & PVE::VZDump::Plugin (pve-guest-common, so okay) -> PVE::API2Tools (pve-manager) so that whole chain can't move to pve-guest-common, and the 'use'=20 statement and call to the API handler can't be there either. a few approaches that might help: - handwave the issue away by calling the vzdump binary instead of the=20 API handler (extra process that needs to be tracked, no way to=20 preserve authuser if we do manual job execution, .., kinda 'meh') - split the plugin definition (which we want to move as low in the=20 dependency tree as possible so that more other packages can use it for=20 job modification) from the 'run' sub for the job type (e.g., by=20 allowing to specify it in the scheduler/pve-manager if the plugin=20 doesn't have one, a simple map of plugin type -> run sub could work) - other great ideas? ;) like I said, the same issue also applies to replication once we convert=20 that to jobs, so any solution would need to take that into account=20 (e.g., the two I mentioned above would work for that as well - via=20 'pvesr' call or leaving the run part in pve-manager and only moving the=20 rest to pve-guest-common). > +use PVE::Cluster; > +use PVE::JSONSchema; > + > +use base qw(PVE::Jobs::Plugin); > + > +sub type { > + return 'vzdump'; > +} > + > +my $props =3D PVE::VZDump::Common::json_config_properties(); > + [..] > + > +sub run { > + my ($class, $conf) =3D @_; > + > + # remove all non vzdump related options > + foreach my $opt (keys %$conf) { > + delete $conf->{$opt} if !defined($props->{$opt}); > + } > + > + my $retention =3D $conf->{'prune-backups'}; > + if ($retention && ref($retention) eq 'HASH') { # fixup, its required= as string parameter > + $conf->{'prune-backups'} =3D PVE::JSONSchema::print_property_string($re= tention, 'prune-backups'); > + } > + > + $conf->{quiet} =3D 1; # do not write to stdout/stderr > + > + PVE::Cluster::cfs_update(); # refresh vmlist > + > + return PVE::API2::VZDump->vzdump($conf); this call here is the problematic one! > +} > + > +1; > --=20 > 2.30.2 >=20 >=20 >=20 > _______________________________________________ > pve-devel mailing list > pve-devel@lists.proxmox.com > https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >=20 >=20 >=20