public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH storage v2 02/10] plugin: dir: implement import content type
Date: Mon, 22 Apr 2024 13:34:29 +0200	[thread overview]
Message-ID: <e301b7f1-9dbf-4420-a553-a677bdf2d5cc@proxmox.com> (raw)
In-Reply-To: <98b79c87-5721-431e-b6a7-f5280ff4d0f4@proxmox.com>

Am 22.04.24 um 13:09 schrieb Dominik Csapak:
> On 4/22/24 13:00, Fiona Ebner wrote:
>> Am 19.04.24 um 11:45 schrieb Dominik Csapak:
>>> diff --git a/src/PVE/Storage/Plugin.pm b/src/PVE/Storage/Plugin.pm
>>> index 22a9729..39a8354 100644
>>> --- a/src/PVE/Storage/Plugin.pm
>>> +++ b/src/PVE/Storage/Plugin.pm
>>> @@ -654,6 +654,10 @@ sub parse_volname {
>>>       return ('backup', $fn);
>>>       } elsif ($volname =~ m!^snippets/([^/]+)$!) {
>>>       return ('snippets', $1);
>>> +    } elsif ($volname =~
>>> m!^import/(${PVE::Storage::SAFE_CHAR_CLASS_RE}+$PVE::Storage::IMPORT_EXT_RE_1)$!) {
>>> +    return ('import', $1);
>>
>> Wouldn't it be nicer to return 'ovf' and 'ova' as the $file_format here
>> and check for that at the call sites? Currently you rely on the presence
>> or absence of $file_format in copy_needs_extraction() and
>> get_import_metadata() and then re-match on the ova extension. Having the
>> format right away would be a bit cleaner and more future-proof or is
>> there a specific reason against doing it?
> 
> i explained it in either the cover letter or in some commit message,
> probably would have fit
> in here too:
> 
> we currently only support raw/vmdk/qcow2/subvol here and it is intended
> only for image formats
> IIUC.

Hmm, maybe we can lift that limitation? Needs a bit of consideration of
course, but I don't see why the format returned by parse_volname()
should be limited to images, since there already is a vtype to
distinguish. And your series already uses the format for 'import' vtype
too ;)

> Also we would have to adapt the `verify_format` for that, since it
> will be
> tested by that at least once. (not sure where exactly though, found out
> by testing)
> and that would mean we could set it as 'default' format on the storage,
> which is not what we want...
> 

We shouldn't allow that of course, but I don't see verify_format()
called other than for the "pve-storage-format" schema format, so maybe
some other check that fails? Or some use site of "pve-storage-format"
that should first check that it's an image? And I guess we should rename
it to "pve-storage-image-format", because it's used as that to avoid
future confusion.


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2024-04-22 11:34 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19  9:45 [pve-devel] [PATCH storage/qemu-server/manager v2] implement ova/ovf import for file based storages Dominik Csapak
2024-04-19  9:45 ` [pve-devel] [PATCH storage v2 01/10] copy OVF.pm from qemu-server Dominik Csapak
2024-04-19  9:45 ` [pve-devel] [PATCH storage v2 02/10] plugin: dir: implement import content type Dominik Csapak
2024-04-22 11:00   ` Fiona Ebner
2024-04-22 11:09     ` Dominik Csapak
2024-04-22 11:34       ` Fiona Ebner [this message]
2024-04-22 11:56         ` Dominik Csapak
2024-04-22 12:14           ` Fiona Ebner
2024-04-19  9:45 ` [pve-devel] [PATCH storage v2 03/10] plugin: dir: handle ova files for import Dominik Csapak
2024-04-19  9:45 ` [pve-devel] [PATCH storage v2 04/10] ovf: implement parsing the ostype Dominik Csapak
2024-04-19  9:45 ` [pve-devel] [PATCH storage v2 05/10] ovf: implement parsing out firmware type Dominik Csapak
2024-04-19  9:45 ` [pve-devel] [PATCH storage v2 06/10] ovf: implement rudimentary boot order Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH storage v2 07/10] ovf: implement parsing nics Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH storage v2 08/10] api: allow ova upload/download Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH storage v2 09/10] plugin: enable import for nfs/btrfs/cifs/cephfs/glusterfs Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH storage v2 10/10] add 'import' content type to 'check_volume_access' Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH qemu-server v2 1/4] api: delete unused OVF.pm Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH qemu-server v2 2/4] use OVF from Storage Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH qemu-server v2 3/4] api: create: implement extracting disks when needed for import-from Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH qemu-server v2 4/4] api: create: add 'import-extraction-storage' parameter Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH manager v2 1/6] ui: fix special 'import' icon for non-esxi storages Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH manager v2 2/6] ui: guest import: add ova-needs-extracting warning text Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH manager v2 3/6] ui: enable import content type for relevant storages Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH manager v2 4/6] ui: enable upload/download/remove buttons for 'import' type storages Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH manager v2 5/6] ui: guest import: add storage selector for ova extraction storage Dominik Csapak
2024-04-19  9:46 ` [pve-devel] [PATCH manager v2 6/6] ui: guest import: change icon/text for non-esxi import storage Dominik Csapak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e301b7f1-9dbf-4420-a553-a677bdf2d5cc@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal