Am 18.04.24 um 09:22 schrieb Fiona Ebner: >>>> diff --git a/src/PVE/Storage.pm b/src/PVE/Storage.pm >>>> index f8ea93d..bc073ef 100755 >>>> --- a/src/PVE/Storage.pm >>>> +++ b/src/PVE/Storage.pm >>>> @@ -2189,4 +2189,63 @@ sub get_import_metadata { >>>> return $plugin->get_import_metadata($scfg, $volname, $storeid); >>>> } >>>> >>> >>> Shouldn't the following three functions call into plugin methods >>> instead? That'd seem much more future-proof to me. >> >> could be, i just did not want to extend the plugin api for that >> but as fabian wrote, maybe we should put them in qemu-server >> altogether for now? >> >> (after thinking about it a bit, i'd be in favor of putting it in >> qemu-server, because mainly i don't want to add to the plugin api further) >> >> what do you think @fiona @fabian? >> > > Doesn't that kinda defeat the purpose to move OVF here? Ideally > qemu-server just uses the import storage API without any knowledge about > how the import content is organized by the storage layer. I mean we > could potentially avoid extending the plugin API by doing the "extract > upon upload". I'd prefer to extend the plugin API, because other future
To clarify, here I mean: "I'd prefer to extend the plugin API if we don't go for "extract upon upload"". > plugins might also want to offer archive-based import, but if we really > don't want to do it for now, fine by me too. > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel