Re: [pve-devel] [PATCH v12 qemu-server 11/16] api: add endpoint for parsing .ovf files

[Fabian Ebner <f.ebner@proxmox.com>]

Am 14.03.22 um 16:55 schrieb Fabian Grünbichler:
> On March 9, 2022 11:09 am, Fabian Ebner wrote:
>> +__PACKAGE__->register_method ({
>> +    name => 'index',
>> +    path => '',
>> +    method => 'GET',
>> +    proxyto => 'node',
>> +    description => "Read an .ovf manifest.",
> 
> protected => 1,
> 
> else this is limited to files readable by www-data?

Ack.

> 
> also probably should think about how to integrate this into the 
> permission system, since being limited to root@pam is rather limiting ;)
> 
> e.g., something like a new content type/subdir for importing that 'only' 
> requires Datastore.Allocate (not AllocateSpace) or a new priv?
> 
> starting off like it is now is of course okay, but we probably want some 
> form of nicer import flow for the common cases (like, download OVA from 
> URL into import dir on storage foo, then import from there for example).
> 

Will revisit when we add that.

>> +    parameters => {
>> +	additionalProperties => 0,
>> +	properties => {
>> +	    node => get_standard_option('pve-node'),
>> +	    manifest => {
>> +		description => "Path to .ovf manifest.",
>> +		type => 'string',
>> +	    },
>> +	},
>> +    },
>> +    returns => {
>> +	description => "VM config according to .ovf manifest.",
>> +	type => "object",
>> +    },
>> +    returns => {
>> +	type => 'object',
>> +	additionalProperties => 1,
>> +	properties => PVE::QemuServer::json_ovf_properties({}),
>> +    },
> 
> duplicate returns key, I guess we want the combination of both here ;)
> 

Will fix it.

>> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
>> index 33f226e..ecf51f3 100644
>> --- a/PVE/QemuServer.pm
>> +++ b/PVE/QemuServer.pm
>> @@ -2203,6 +2203,38 @@ sub json_config_properties {
>>      return $prop;
>>  }
>>  
>> +# Properties that we can read from an OVF file
>> +sub json_ovf_properties {
>> +    my $prop = shift;
> 
> not sure whether we need the $prop here instead of always starting with 
> a clean slate? is there some future extension that uses this that you 
> have in mind?
> 

It was actually used in such a way in Dominic's version, because the
non-drive properties were passed along as $prop. But yes, it can be
dropped now.