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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 4ACAE6D5BA for ; Thu, 1 Apr 2021 13:30:34 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 3EE301AE57 for ; Thu, 1 Apr 2021 13:30:34 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (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 0E7381AE4A for ; Thu, 1 Apr 2021 13:30:33 +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 D2C4142949 for ; Thu, 1 Apr 2021 13:30:32 +0200 (CEST) Date: Thu, 01 Apr 2021 13:30:24 +0200 From: Fabian =?iso-8859-1?q?Gr=FCnbichler?= To: Dominic =?iso-8859-1?b?SuRnZXI=?= , Proxmox VE development discussion References: <20210326123227.137243-1-d.jaeger@proxmox.com> <20210326123227.137243-2-d.jaeger@proxmox.com> <1617202583.o619p5czdy.astroid@nora.none> <20210401101908.GA80830@mala> In-Reply-To: <20210401101908.GA80830@mala> MIME-Version: 1.0 User-Agent: astroid/0.15.0 (https://github.com/astroidmail/astroid) Message-Id: <1617276240.ktgmc02ewf.astroid@nora.none> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-LEVEL: Spam detection results: 0 AWL 0.027 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [qemu.pm] Subject: Re: [pve-devel] [PATCH v7 qemu-server] Add API for import wizards 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: Thu, 01 Apr 2021 11:30:34 -0000 On April 1, 2021 12:19 pm, Dominic J=C3=A4ger wrote: > On Wed, Mar 31, 2021 at 05:12:28PM +0200, Fabian Gr=C3=BCnbichler wrote: >> this is starting to shape up nicely. as promised, I now took a stab at=20 >> (roughly!) integrating this into our regular flow (see diff below): >> .... >>=20 >> - we could likely drop the separate import_disk API call, and let the=20 >> `importdisk` CLI command prepare parameters for a regular VM config=20 >> update > I think dropping importdisk is a good idea, too. >=20 >> I'm sure I've missed some corner cases, as I've only tested create_vm=20 >> with importing, and not the other newly exposed APIs. >=20 > I didn't get the importdisk API to work yet. > But I'd look closer at stuff like that > if (!$device_options) { > $device_options =3D "$storeid:0"; <=3D=3D=3D should be -1 > } > only if we keep it? >=20 > One thing is important: That import parameter was at the place of the def= ault storage yes, I just roughly moved the code to see whether the approach works out=20 and then tested a single entry point. if there are no objections into=20 merging it like that, it would definitely need a cleanup and more=20 testing :) >=20 > PVE/API2/Qemu.pm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/PVE/API2/Qemu.pm b/PVE/API2/Qemu.pm > index 41e1ab7..73af497 100644 > --- a/PVE/API2/Qemu.pm > +++ b/PVE/API2/Qemu.pm > @@ -1469,7 +1469,7 @@ my $update_vm_api =3D sub { > PVE::QemuServer::vmconfig_register_unused_drive($storecfg, $vmid, = $conf, PVE::QemuServer::parse_drive($opt, $conf->{pending}->{$opt})) > if defined($conf->{pending}->{$opt}); > =20 > - &$create_disks($rpcenv, $authuser, $conf->{pending}, $arch, $store= cfg, $vmid, undef, {$opt =3D> $param->{$opt}}, {$opt =3D> $import_devices->= {$opt}}); > + &$create_disks($rpcenv, $authuser, $conf->{pending}, $arch, $store= cfg, $vmid, undef, {$opt =3D> $param->{$opt}}, undef, {$opt =3D> $import_de= vices->{$opt}}); > } elsif ($opt =3D~ m/^serial\d+/) { > if ((!defined($conf->{$opt}) || $conf->{$opt} eq 'socket') && $par= am->{$opt} eq 'socket') { > $rpcenv->check_vm_perm($authuser, $vmid, undef, ['VM.Config.HWType'])= ; >=20 >=20 >> stat shows how much boilerplace/duplication this removes, although there= =20 >> is probably even more potential here since `create_vm` partly duplicates= =20 >> the `update_vm_api` sub that ends up calling `create_disks`: > Is that urgent? no, it's just something I noticed since I added the same code in the=20 same context in two places ;) =