all lists on lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Friedrich Weber <f.weber@proxmox.com>,
	Lukas Sichert <l.sichert@proxmox.com>,
	pve-devel@lists.proxmox.com
Subject: Re: [PATCH storage v3 1/2] fix #7339: lvmthick: add worker to free space of to be deleted VMs
Date: Thu, 7 May 2026 11:47:26 +0200	[thread overview]
Message-ID: <3b8cb9b3-4155-4878-9ef3-5c0de0200f48@proxmox.com> (raw)
In-Reply-To: <8cb01407-870d-4166-9f27-7fc2fe0ae4a6@proxmox.com>

Am 06.05.26 um 12:10 schrieb Friedrich Weber:
> On 06/05/2026 11:57, Lukas Sichert wrote:
>> On 2026-05-05 17:59, Friedrich Weber <f.weber@proxmox.com> wrote:

...

>> That said, this is also suboptimal because if other plugins return
>> worker tasks from their '$free_image' implementations, then their
>> descriptions could also be altered if these flags are set. In the
>> default Proxmox stack this is currently not the case, but it could
>> affect external plugins.

Yeah, this is IMO not really the right level for this. I.e., some
storage specific edge case in the generic plugin storage interface.

>> Another option would be to rename the displayed name for an 'imgdel'
>> task in the UI to 'Destroy image'. That would fit the generic worker
>> task better and would also make the naming consistent with
>> 'unknownimgdel', which is currently displayed as
>> 'Destroy image from unknown guest'.
> 
> Yeah, changing the GUI description of 'imgdel' like that could be an
> option! Though of course there is also some confusion potential there,
> especially for users who upgrade.

FWIW, I also think that it's not perfect, but at least much simpler
and doesn't changes/adds any worker task type, and in addition to that
the respective storage plugins could do a worker task log with such
info in higher detail.

> 
> What do others think?
> 
>>
>> Does anybody have opinions on how to go forward with this?

See above, the approach here breaks abstraction boundaries, so IMO
not acceptable for the ROI we get, so would rather live with the
tradeoffs of the UI + task log solution over this.




  reply	other threads:[~2026-05-07  9:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-23 14:47 [PATCH manager/storage v3 0/2] fix #7339: lvmthick: add option to free storage for deleted VMs Lukas Sichert
2026-04-23 14:47 ` [PATCH storage v3 1/2] fix #7339: lvmthick: add worker to free space of to be " Lukas Sichert
2026-05-05 15:59   ` Friedrich Weber
2026-05-06  9:59     ` Lukas Sichert
2026-05-06 10:11       ` Friedrich Weber
2026-05-07  9:47         ` Thomas Lamprecht [this message]
2026-04-23 14:47 ` [PATCH manager v3 2/2] fix #7339: lvmthick: ui: add UI fields for option to free storage Lukas Sichert

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=3b8cb9b3-4155-4878-9ef3-5c0de0200f48@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=f.weber@proxmox.com \
    --cc=l.sichert@proxmox.com \
    --cc=pve-devel@lists.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