[pve-devel] [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity

[pve-devel] [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity

[Thomas Lamprecht]

If we run out of passed arguments from the user but still had defined
"arg_params" (those params which went after the command in fixed
order without option -- dashes) we always errored out with "not
enough arguments". But, there are situations where the remaining
arg_params are all marked as optional in the schema, so we do not
need to error out in that case.

Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
---

A prime (future) use case is "pvesm prune-backups". Currently the
usage is:
> pvesm prune-backups storeid --prune-backups keep-last=1,keep-...

Because the "prune-backups" keep retention property is optional as it
can fallback to the one defined in the storage configuration.
With this patch we can make it an argument and allow the following
two usages:

1. As above, but avoiding the extra ugly --prune-backups
> pvesm prune-backups storeid keep-last=1,keep-...

2. Fallback to storage config:
> pvesm prune-backups storeid

 src/PVE/JSONSchema.pm | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/PVE/JSONSchema.pm b/src/PVE/JSONSchema.pm
index c5002d8..2ceb1bd 100644
--- a/src/PVE/JSONSchema.pm
+++ b/src/PVE/JSONSchema.pm
@@ -1613,7 +1613,8 @@ sub get_options {
 	    $opts->{$list_param} = $args;
 	    $args = [];
 	} elsif (ref($arg_param)) {
-	    foreach my $arg_name (@$arg_param) {
+	    for (my $i = 0; $i < scalar(@$arg_param); $i++) {
+		my $arg_name = $arg_param->[$i];
 		if ($opts->{'extra-args'}) {
 		    raise("internal error: extra-args must be the last argument\n", code => HTTP_BAD_REQUEST);
 		}
@@ -1622,7 +1623,15 @@ sub get_options {
 		    $args = [];
 		    next;
 		}
-		raise("not enough arguments\n", code => HTTP_BAD_REQUEST) if !@$args;
+		if (!@$args) {
+		    # check if all left-over arg_param are optional, else we
+		    # must die as the mapping is then ambigious
+		    for (my $j = $i; $j < scalar(@$arg_param); $j++) {
+			my $prop = $arg_param->[$j];
+			raise("not enough arguments\n", code => HTTP_BAD_REQUEST)
+			    if !$schema->{properties}->{$prop}->{optional};
+		    }
+		}
 		$opts->{$arg_name} = shift @$args;
 	    }
 	    raise("too many arguments\n", code => HTTP_BAD_REQUEST) if @$args;
-- 
2.20.1

Re: [pve-devel] [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity

[Dietmar Maurer]

> If we run out of passed arguments from the user but still had defined
> "arg_params" (those params which went after the command in fixed
> order without option -- dashes) we always errored out with "not
> enough arguments". But, there are situations where the remaining
> arg_params are all marked as optional in the schema, so we do not
> need to error out in that case.

Ok for me, but

> A prime (future) use case is "pvesm prune-backups". Currently the
> usage is:
> > pvesm prune-backups storeid --prune-backups keep-last=1,keep-...

I would like to have a different CLI for that:

pvesm prune-backups storeid --keep-last 2 --keep-weekly 5

any opinions?

Re: [pve-devel] [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity

[Thomas Lamprecht]

On 27.08.20 06:22, Dietmar Maurer wrote:
> 
>> If we run out of passed arguments from the user but still had defined
>> "arg_params" (those params which went after the command in fixed
>> order without option -- dashes) we always errored out with "not
>> enough arguments". But, there are situations where the remaining
>> arg_params are all marked as optional in the schema, so we do not
>> need to error out in that case.
> 
> Ok for me, but
> 
>> A prime (future) use case is "pvesm prune-backups". Currently the
>> usage is:
>>> pvesm prune-backups storeid --prune-backups keep-last=1,keep-...
> 
> I would like to have a different CLI for that:
> 
> pvesm prune-backups storeid --keep-last 2 --keep-weekly 5
> 
> any opinions?
> 

Fine for me!

@Fabi, can you take a look at this?

Effectively we just need to use the 'prune-backups' format defiinitions
$prune_backups_format hash from Storage::Plugin directly as parameter,
then we can map and pass it along to the helper.

Re: [pve-devel] [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity

[Fabian Ebner]

Am 27.08.20 um 08:39 schrieb Thomas Lamprecht:
> On 27.08.20 06:22, Dietmar Maurer wrote:
>>
>>> If we run out of passed arguments from the user but still had defined
>>> "arg_params" (those params which went after the command in fixed
>>> order without option -- dashes) we always errored out with "not
>>> enough arguments". But, there are situations where the remaining
>>> arg_params are all marked as optional in the schema, so we do not
>>> need to error out in that case.
>>
>> Ok for me, but
>>
>>> A prime (future) use case is "pvesm prune-backups". Currently the
>>> usage is:
>>>> pvesm prune-backups storeid --prune-backups keep-last=1,keep-...
>>
>> I would like to have a different CLI for that:
>>
>> pvesm prune-backups storeid --keep-last 2 --keep-weekly 5
>>
>> any opinions?
>>
> 
> Fine for me!
> 
> @Fabi, can you take a look at this?
> 
> Effectively we just need to use the 'prune-backups' format defiinitions
> $prune_backups_format hash from Storage::Plugin directly as parameter,
> then we can map and pass it along to the helper.
> 

Yes, will do.

[pve-devel] applied: [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity

[Thomas Lamprecht]

On 26.08.20 21:27, Thomas Lamprecht wrote:
> If we run out of passed arguments from the user but still had defined
> "arg_params" (those params which went after the command in fixed
> order without option -- dashes) we always errored out with "not
> enough arguments". But, there are situations where the remaining
> arg_params are all marked as optional in the schema, so we do not
> need to error out in that case.
> 
> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
> ---
> 
> A prime (future) use case is "pvesm prune-backups". Currently the
> usage is:
>> pvesm prune-backups storeid --prune-backups keep-last=1,keep-...
> 
> Because the "prune-backups" keep retention property is optional as it
> can fallback to the one defined in the storage configuration.
> With this patch we can make it an argument and allow the following
> two usages:
> 
> 1. As above, but avoiding the extra ugly --prune-backups
>> pvesm prune-backups storeid keep-last=1,keep-...
> 
> 2. Fallback to storage config:
>> pvesm prune-backups storeid
> 
>  src/PVE/JSONSchema.pm | 13 +++++++++++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
>


while Dietmars proposal to move the example above to another format,
more similar to the one from proxmox-backup, is better; this is still
nice to have, so: applied

Re: [pve-devel] applied: [PATCH common] get_options: allow optional arguments "arg_params" if no ambiguity

[Fabian Grünbichler]

On August 27, 2020 10:54 am, Thomas Lamprecht wrote:
> On 26.08.20 21:27, Thomas Lamprecht wrote:
>> If we run out of passed arguments from the user but still had defined
>> "arg_params" (those params which went after the command in fixed
>> order without option -- dashes) we always errored out with "not
>> enough arguments". But, there are situations where the remaining
>> arg_params are all marked as optional in the schema, so we do not
>> need to error out in that case.
>> 
>> Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
>> ---
>> 
>> A prime (future) use case is "pvesm prune-backups". Currently the
>> usage is:
>>> pvesm prune-backups storeid --prune-backups keep-last=1,keep-...
>> 
>> Because the "prune-backups" keep retention property is optional as it
>> can fallback to the one defined in the storage configuration.
>> With this patch we can make it an argument and allow the following
>> two usages:
>> 
>> 1. As above, but avoiding the extra ugly --prune-backups
>>> pvesm prune-backups storeid keep-last=1,keep-...
>> 
>> 2. Fallback to storage config:
>>> pvesm prune-backups storeid
>> 
>>  src/PVE/JSONSchema.pm | 13 +++++++++++--
>>  1 file changed, 11 insertions(+), 2 deletions(-)
>> 
>>
> 
> 
> while Dietmars proposal to move the example above to another format,
> more similar to the one from proxmox-backup, is better; this is still
> nice to have, so: applied

we probably also want this for the else branch (when all arguments are 
optional and none are given), if just for consistency. one example: 'qm 
rescan' could move from 'qm rescan [--vmid VMID] [..]' to 'qm rescan 
[VMID] [..]'. the doc generator seems to handle that correctly already, 
so maybe we even already have cases where the docs indicate optionality 
but the schema does not allow it? :-P