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 20DF278C89 for ; Thu, 30 Jun 2022 09:52:03 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 109402C4A5 for ; Thu, 30 Jun 2022 09:51:33 +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 for ; Thu, 30 Jun 2022 09:51:32 +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 43AE440AB4; Thu, 30 Jun 2022 09:51:32 +0200 (CEST) Message-ID: <22fe96b6-9fd5-51f2-6ef9-e42a1f6cd3be@proxmox.com> Date: Thu, 30 Jun 2022 09:51:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0 Content-Language: en-GB To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , "aderumier@odiso.com" References: <20220629090833.456340-1-aderumier@odiso.com> <20220629090833.456340-5-aderumier@odiso.com> From: Thomas Lamprecht In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.004 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 NICE_REPLY_A -0.001 Looks like a legit reply (A) 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 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [firewall.pm] Subject: Re: [pve-devel] [PATCH pve-common 1/1] schema: add pve-targetstorage (moved from qemu-server) 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, 30 Jun 2022 07:52:03 -0000 On 30/06/2022 09:30, DERUMIER, Alexandre wrote: >> this and "qemu-server: remove json schema pve-targetstorage (moved to >> pve-common)" >> seems rather unrelated from the firewall series. >> > I haved added it, because if you remove "use Firewall.pm" from lxc, > > it's doesn't find the schema anymore (because QemuServer is require in > Firewall.pm) > Ah, ok, so an implicit, "invisible" dependency from pve-container to qemu-server, yuck. Then I understand the relation (could be more obviously noted in a commit message though :-) - anyhow > > But yes, it could be done firstly in another patch series. (and It seem > than fabian has already send a patch some months ago) > > I can take a look a the ones from Fabian so we can get that out of the way first. > BTW, Do you known why we need in pve-firewall :> > # dynamically include PVE::QemuServer and PVE::LXC> # to avoid dependency problems> my $have_qemu_server;> eval {> require PVE::QemuServer;> require PVE::QemuConfig;> $have_qemu_server = 1;> };> > my $have_lxc;> eval {> require PVE::LXC;> $have_lxc = 1;> };> > > > ?> > is it because PVE::Qemuserver && PVE::LXC are also using use> PVE::Firewall ?> Yes. It's mostly to allow solving the circular dependency issue for bootstrapping PVE in a easy way, e.g., for a new Debian release like Bookworm next year. I mean, we only uses it to parse the networks of VM/CTs, maybe we could reorganise that - from top of my head: either write a simple standalone parser in firewall that gets out the relevant info or split out the config schema stuff in separate packages for each VM and CTs, which could be a bit more work but maybe fit in our project to convert more of the schema from perl to rust (for datacenter manager). Anyhow, that is probably not as important now and can stay as is with the eval'd requires.