[pve-devel] [RFC common] add 'pve-vmid-optional' format and standard option

[Thomas Lamprecht]

On 10/18/2016 08:56 AM, Fabian Grünbichler wrote:
> On Mon, Oct 17, 2016 at 05:44:34PM +0200, Thomas Lamprecht wrote:
>> This will be used in cases where the VMID may not be important. For
>> example some users do not care which VMID a CT/VM gets, they just
>> want a CT/VM.
>>
>> Signed-off-by: Thomas Lamprecht <t.lamprecht at proxmox.com>
>> ---
>>   src/PVE/JSONSchema.pm | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/src/PVE/JSONSchema.pm b/src/PVE/JSONSchema.pm
>> index caeefe2..7a4a601 100644
>> --- a/src/PVE/JSONSchema.pm
>> +++ b/src/PVE/JSONSchema.pm
>> @@ -56,6 +56,11 @@ register_standard_option('pve-vmid', {
>>       minimum => 1
>>   });
>>   
>> +register_standard_option('pve-vmid-optional', {
>> +    description => "The (unique) ID of the VM or a '.' to autogenerate one.",
>> +    type => 'string', format => 'pve-vmid-optional',
>> +});
>> +
>>   register_standard_option('pve-node', {
>>       description => "The cluster node name.",
>>       type => 'string', format => 'pve-node',
>> @@ -155,6 +160,17 @@ sub pve_verify_vmid {
>>       return $vmid;
>>   }
>>   
>> +register_format('pve-vmid-optional', \&pve_verify_vmid_optional);
>> +sub pve_verify_vmid_optional {
>> +    my ($vmid, $noerr) = @_;
>> +
>> +    if ($vmid !~ m/^([1-9][0-9]{2,8}|\.)$/) {
>> +	return undef if $noerr;
>> +	die "value does not look like a valid optional VM ID\n";
>> +    }
>> +    return $vmid;
>> +}
>> +
>>   register_format('pve-node', \&pve_verify_node_name);
>>   sub pve_verify_node_name {
>>       my ($node, $noerr) = @_;
>> -- 
>> 2.1.4
>>
> why not make it actually optional instead of the '.' means autogenerated
> workaround? either actually make it optional, or don't call it optional
> ;) the backwards compatibility would only be needed for pct and
> qm[restore], because there the ID is the first parameter. but since
> those already wrap around the actual API, you could have this workaround
> limited to the CLI tools, and for the real API the vmid becomes optional

It was first optional but that gives problems and interferes with the 
REST design.
The creating object (or its path) itself should be unique.
Calling it pve-vmid-auto (or similar) would be the fix here, imo. :)

> if you want to stick with the "special value to autogenerate" thing,
> I think I'd prefer a more readable value then '.' - since the actual
> IDs are numeric, we could even use something like "auto" or "generate"?

auto is more reasonable but has the same problem with the actual IDs 
being integer ;)
'0' would be an option where the specification of our VMID still holds, 
but maybe still not that reasonable.