Previously, the returned value would be only the last element or undef in case
of an empty list. There's only a handful of callers of check_format() that look
at the return value and AFAICT none of the exisitng ones is for a -list format.
But best to avoid any future surprises.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Currently this happened if (and only if) at least one
positional parameter was passed.
We run into this with
`pmgconfig cert delete <type> [<restart>]`
vs
`pvenode cert delete [<restart>]`
where in the PVE case the `restart` option was simply
omitted, whereas for PMG due to the existence of `<type>`
the `restart` option was explicitly passedset in the $opts
hash but ended up being `undef`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Shellquote is needed for '~', and while it doesn't help with '-',
there should be no problem, because options are separated from mailto
since commit 216a3f4f13.
Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
Reviewed-By: Dominik Csapak <d.csapak@proxmox.com>
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.
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
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Adds a third, optional parameter to register_format that allows specifying
a function that will be called after parsing and can validate the parsed
data. A validator should die on failed validation, and can also change the
parsed object by returning a modified version of it.
This is useful so one can register a format with its hash, thus allowing
documentation to be generated automatically, while still enforcing certain
validation rules.
The validator only needs to be called in parse_property_string, since
check_format always calls parse_property_string if there is a
possibility of a validator existing at all. parse_property_string should
then be called with named formats for best effect, as only then can
validators be used.
Clean up 'check_format' as well (which pretty much amounts to a rewrite).
No existing functionality is intentionally changed.
Signed-off-by: Stefan Reiter <s.reiter@proxmox.com>
/usr/share/zoneinfo/zone.tab has the valid list of time zones.
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
we use this format for all 'delete' options but we have some options
that have a '-' in the name (e.g. 'sync-defaults-options') that cannot
be deleted if it is not included
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
By using "exists" when checking if a hash entry is set, else things
like "0" could get accepted by mistake.
Also cleanup the code a little, like dropping the "PVE::JSONSchema::"
prefix, this is now in that module after all.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
generalized from the start to support extension to bridges or other
entities as well.
this gets us incremental support for the CLI, e.g.:
--targetstorage foo:bar --targetstorage bar:baz --targetstorage foo
creates a mapping of
foo=>bar
bar=>baz
with a default of foo
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
to mark which API methods should be available to clients authenticated using an API token.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
this will be used for vm/ct tag-lists, so that (config) management systems
or similar add additional information that does not reside in the
description
putting it here, since we want to eventually have it also for
nodes,storages,etc.
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
The old format used 16 base32 chars or 40 hex digits. Since they have
a common subset it's hard to distinguish them without the our
previous length constraints, so prefix a 'v2-' of the format to
support arbitrary lengths properly.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
move it from qemu-server as it was also used in pve-container and
pve-manager (pvesr), while guest-commons AbstractConfig could be a
fit too, just move it here as all depending on this already use
JSONSchema and it just fits here...
Break respective qemu-server version
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
MAC-addresses having the LSB of the first octet set, are considered
multicast-addresses (see [0,1]).
the 'mac-addr' format got changed to only permit unicast addresses, which should
work for its current use-case (WOL for nodes).
additionally a default option was registered via register_standard_option to be
used in both PVE::LXC::Config and PVE::QemuServer.
[0] https://lists.linuxcontainers.org/pipermail/lxc-users/2010-August/000783.html
[1] https://en.wikipedia.org/wiki/MAC_address
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
now allows:
* addresses without tld (f.e. user@localhost per bug)
* remove limits for number of subdomains
* allow +, -, ~ in local part
* disallow double dots (.. .a. etc) and dots in the end (abc.@mail.com)
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Acked-by: Dominik Csapak <d.csapak@proxmox.com>
we have a param_mapping now, with which we can impement that
e.g. instead of using:
sub read_password {
# read password
}
we can do:
sub param_mapping {
my ($name) = @_;
my $password_map = ['password', sub{
# read password
}, '<password', 1];
my $mapping = {
'apicall1' => [$password_map],
'apicall2' => [$password_map],
...
};
return $mapping->{$name};
}
this has the advantage that we can use different subs for different
api calls (e.g. pveum passwd vs pveum ticket)
if a CLIHandler implemenation still has a read_password sub and no
param_mapping, we generate one for them with read_password as the
sub for the standard mapping 'pve-password'
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Instead of hardcoding 'password' as a special case in the
JSONSchema's getopt handling, extend the new parameter
mapping to allow defining a parameters as 'interactive'.
They also take an optional argument on the command line
directly.
This effectively deprecates the password special case which
should be replaced in pct/pveum/... and then dropped in
pve-common.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
