From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 0C7231FF37F for ; Thu, 18 Apr 2024 11:27:32 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E427E182E2; Thu, 18 Apr 2024 11:27:26 +0200 (CEST) Message-ID: <9ac3ddcc-854e-45f6-be6d-fc157b68d186@proxmox.com> Date: Thu, 18 Apr 2024 11:27:24 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta From: Dominik Csapak To: pve-devel@lists.proxmox.com References: <20240416131909.2867605-1-d.csapak@proxmox.com> Content-Language: en-US In-Reply-To: <20240416131909.2867605-1-d.csapak@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.014 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy 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 Subject: Re: [pve-devel] [PATCH storage/qemu-server/pve-manager] implement ova/ovf import for directory type storages 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: , Reply-To: Proxmox VE development discussion Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" ok after a bit of thinking and discussing off-list the plan to go forward from my side is this: (please tell if there is something obviously wrong with it or you'd strongly prefer something differently) extract on demand vs on upload: i'd go with extract on demand because managing the extraction of the tarball + subdir etc is not really a win in my book, since we have to have most safeguards anyway and we have the same issue of where to store/map it etc. also it's not convenient for users that have already a bunch of ovas and want to store them in a central place, now they'd have to extract them just for us (and importing should be as small a hassle as it can be) for placing the extract code, i'd strongly prefer the (future) PVE::GuestImport namespace in pve-storage, as that does not pollute the plugin api with irrelevant stuff and is relatively far away from qemu-server (so we could reuse it later for other things if we need to) as for the extraction/cleanup step: i'll reuse the 'images' part of the storage to extract it there with a valid vm disk name. that way if the cleanup fails, it can be deleted from the ui at least if the storage does not have an images content type or the user does not have the relevant privileges, i'd force the user to provide (with a new parameter for creating) a file based storage with content type images. that can be shown in the gui only for ova imports. (and would default to the import storage if possible) i think that were all the "big" questions for this series, please do tell if i forgot something ;) if no one objects to these things (or has even better ideas to solve some of these), i'd get started on that ASAP _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel