a bit strange to be honest, there's already:
# pct unlock VMID
doing the same thing in a completely other matter,
using LXC::Config->remove_lock (inherited from AbstractConfig)
Ideally, both the API and the CLI helper share their code, after your patch.
I'd not allow changing params on a locked VM, to much strange side effects..
Allow to remove the lock as its own operation, then a user can do everything
again.
What about VMs?
On 3/16/18 5:30 PM, Alwin Antreich wrote:
> Signed-off-by: Alwin Antreich <a.antre...@proxmox.com>
> ---
> src/PVE/API2/LXC/Config.pm | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/src/PVE/API2/LXC/Config.pm b/src/PVE/API2/LXC/Config.pm
> index 2b622b3..2d69049 100644
> --- a/src/PVE/API2/LXC/Config.pm
> +++ b/src/PVE/API2/LXC/Config.pm
> @@ -80,6 +80,7 @@ __PACKAGE__->register_method({
> {
> node => get_standard_option('pve-node'),
> vmid => get_standard_option('pve-vmid', { completion =>
> \&PVE::LXC::complete_ctid }),
> + skiplock => get_standard_option('skiplock'),
> delete => {
> type => 'string', format => 'pve-configid-list',
> description => "A list of settings you want to delete.",
> @@ -107,6 +108,10 @@ __PACKAGE__->register_method({
>
> my $digest = extract_param($param, 'digest');
>
> + my $skiplock = extract_param($param, 'skiplock');
> + raise_param_exc({ skiplock => "Only root may use this option." })
> + if $skiplock && $authuser ne 'root@pam';
> +
> die "no options specified\n" if !scalar(keys %$param);
>
> my $delete_str = extract_param($param, 'delete');
> @@ -155,7 +160,7 @@ __PACKAGE__->register_method({
> my $code = sub {
>
> my $conf = PVE::LXC::Config->load_config($vmid);
> - PVE::LXC::Config->check_lock($conf);
> + PVE::LXC::Config->check_lock($conf) if !$skiplock;
>
> PVE::Tools::assert_if_modified($digest, $conf->{digest});
>
>
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
