all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
To: Stefan Hrdlicka <s.hrdlicka@proxmox.com>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH pve-container 1/3] fix #3711: enable delete of LXC container via force option
Date: Fri, 22 Jul 2022 14:25:49 +0200	[thread overview]
Message-ID: <20220722122549.e7jtwfdhy2bymluh@wobu-vie.proxmox.com> (raw)
In-Reply-To: <20220720144949.1568323-2-s.hrdlicka@proxmox.com>

On Wed, Jul 20, 2022 at 04:49:47PM +0200, Stefan Hrdlicka wrote:
> Make it possible to delete a container whoes underlying storage is no
> longer available. This will just write an warning instead of dying.

"no longer available" != "throws errors" (see below (*))

> 
> Without setting the option force-remove-storage=1 a delete will still
> fail, like it did before the changes. With this option set it will try to
> delete the volume from the storage. If this fails it writes a warning.
> 
> Signed-off-by: Stefan Hrdlicka <s.hrdlicka@proxmox.com>
> ---
>  src/PVE/API2/LXC.pm |  8 ++++++++
>  src/PVE/LXC.pm      | 20 +++++++++++++++-----
>  2 files changed, 23 insertions(+), 5 deletions(-)
> 
> diff --git a/src/PVE/API2/LXC.pm b/src/PVE/API2/LXC.pm
> index 589f96f..4d785c9 100644
> --- a/src/PVE/API2/LXC.pm
> +++ b/src/PVE/API2/LXC.pm
> @@ -697,6 +697,13 @@ __PACKAGE__->register_method({
>  		    ." enabled storages which are not referenced in the config.",
>  		optional => 1,
>  	    },
> +	    'force-remove-storage' => {

This name is a bit confusing as instead of enforcing removal you're
actually ignoring the case where removal *fails*, iow.: you allow *not*
removing data.

The `create_vm` call has an `ignore-unpack-errors` parameter, so maybe
`ignore-storage-errors` would work here. (And renaming all the
$variables accordingly.)

> +		type => 'boolean',
> +		description => 'If set, this will ignore errors when trying to remove LXC'

(*) when documenting it as ignoring errors, I would not expect it to
distinguish between unavailable storages and _other_ errors happening.

Side note: Almost all our API docs just refer to them as 'containers',
the 'LXC' portion can be dropped here.

> +		    . ' container storage.',
> +		default => 0,
> +		optional => 1,
> +	    }
>  	},
>      },
>      returns => {
> @@ -758,6 +765,7 @@ __PACKAGE__->register_method({
>  		$conf,
>  		{ lock => 'destroyed' },
>  		$param->{'destroy-unreferenced-disks'},
> +		$param->{'force-remove-storage'},
>  	    );
>  
>  	    PVE::AccessControl::remove_vm_access($vmid);
> diff --git a/src/PVE/LXC.pm b/src/PVE/LXC.pm
> index fe63087..74c8d17 100644
> --- a/src/PVE/LXC.pm
> +++ b/src/PVE/LXC.pm
> @@ -848,13 +848,22 @@ sub get_primary_ips {
>  }
>  
>  sub delete_mountpoint_volume {
> -    my ($storage_cfg, $vmid, $volume) = @_;
> +    my ($storage_cfg, $vmid, $volume, $force_remove_storage) = @_;
>  
>      return if PVE::LXC::Config->classify_mountpoint($volume) ne 'volume';
>  
> -    my ($vtype, $name, $owner) = PVE::Storage::parse_volname($storage_cfg, $volume);
> +    my ($vtype, $name, $owner);
> +    eval {
> +	($vtype, $name, $owner) = PVE::Storage::parse_volname($storage_cfg, $volume);
> +    };

^ It is not clear to me why you'd cover this, but not the `vdisk_free`
below, unless you're trying to catch only specific errors (but this is
not specific enough...)

I think this sub can be left unchanged and instead the
`delete_mountpoint_volume()` call itself could be wrapped in an
`eval{}` instead.

>  
> -    if ($vmid == $owner) {
> +    if (!$force_remove_storage && $@) {
> +	die $@;
> +    } elsif ($@) {
> +	# $force_remove_storage == true is implied here
> +	warn "storage not available, can't remove $volume disk image, continuing!\n"
> +	    . "error: $@\n";
> +    } elsif ($vmid == $owner) {
>  	PVE::Storage::vdisk_free($storage_cfg, $volume);
>      } else {
>  	warn "ignore deletion of '$volume', CT $vmid isn't the owner!\n";
> @@ -862,7 +871,8 @@ sub delete_mountpoint_volume {
>  }
>  
>  sub destroy_lxc_container {
> -    my ($storage_cfg, $vmid, $conf, $replacement_conf, $purge_unreferenced) = @_;
> +    my ($storage_cfg, $vmid, $conf, $replacement_conf,
> +	$purge_unreferenced, $force_remove_storage) = @_;
>  
>      my $volids = {};
>      my $remove_volume = sub {
> @@ -873,7 +883,7 @@ sub destroy_lxc_container {
>  	return if $volids->{$volume};
>  	$volids->{$volume} = 1;
>  
> -	delete_mountpoint_volume($storage_cfg, $vmid, $volume);
> +	delete_mountpoint_volume($storage_cfg, $vmid, $volume, $force_remove_storage);

So I think I'd just put an `eval{}` here, not pass the parameter
through, and just `die $@ if $@ && !$ignore_storage_errrors` afterwards.

>      };
>      PVE::LXC::Config->foreach_volume_full($conf, {include_unused => 1}, $remove_volume);
>  
> -- 
> 2.30.2




  reply	other threads:[~2022-07-22 12:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 14:49 [pve-devel] [PATCH pve-container 0/3] fix #3711: delete LXC container with missing storage Stefan Hrdlicka
2022-07-20 14:49 ` [pve-devel] [PATCH pve-container 1/3] fix #3711: enable delete of LXC container via force option Stefan Hrdlicka
2022-07-22 12:25   ` Wolfgang Bumiller [this message]
2022-07-20 14:49 ` [pve-devel] [PATCH pve-container 2/3] fix #3711 cleanup: remove spaces from empty lines Stefan Hrdlicka
2022-07-22 12:26   ` Wolfgang Bumiller
2022-07-20 14:49 ` [pve-devel] [PATCH pve-manager 3/3] fix #3711: enable removing container with non existent storage Stefan Hrdlicka
2022-07-25 10:40 ` [pve-devel] [PATCH pve-container 0/3] fix #3711: delete LXC container with missing storage Fiona Ebner
2022-07-25 13:31   ` Wolfgang Bumiller
2022-08-05 12:05     ` Stefan Hrdlicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220722122549.e7jtwfdhy2bymluh@wobu-vie.proxmox.com \
    --to=w.bumiller@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=s.hrdlicka@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal