public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Aaron Lauterer <a.lauterer@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH v2 storage 1/2] rbd: improve handling of missing images
Date: Tue, 22 Aug 2023 11:42:37 +0200	[thread overview]
Message-ID: <c5a08c77-992e-48b3-81e8-8e70a0c0136c@proxmox.com> (raw)
In-Reply-To: <edd3bab8-8474-2085-45b0-b5a78d51b6e5@proxmox.com>

Thanks. I'll look into your comments regarding the actual error handling. But 
there is one important question that we need to decide on. See below.

On 8/21/23 17:05, Fiona Ebner wrote:
> Am 14.06.23 um 13:10 schrieb Aaron Lauterer:
>> It can happen, that an RBD image isn't cleaned up 100%. Calling 'rbd ls
>> -l' will then show errors that it is not possible to open the image in
>> question:
>> ```
>> rbd: error opening vm-103-disk-1: (2) No such file or directory
>> rbd: listing images failed: (2) No such file or directory
>> ```
>>
>> Originally we only showed the last error line which is too generic and
>> doesn't give a good hint what is actually wrong.
>>
>> We can improve that by catching these specific errors and add the
>> problematic disk images to the returned list with a size of '-1'.
>>
> 
> What do you think about logging a warning instead, hinting that it might
> be a partially removed image? The thing I'm a bit worried about is that
> existing scripts/tools interacting with our API might get confused by
> the -1. And if I use the UI, I don't see it with either approach,
> because your next patch hides it. If I use the CLI, I'll see either the
> warning or the -1 depending on the approach.
> 

Showing warnings on the CLI is a good idea either way, but the question is, do 
we want to list a broken image? If yes, then the users are more likely to notice 
that something is amiss. If we only log it, then chances are rather low as only 
users who use the CLI will see the warnings.
The downside though is, as you mentioned, that some external tools/scripts might 
be confused about it.

I am not sure how easy it is to pass through a dedicated parameter to the 
storage plugin. If, we could indicate that we want the disk images listed when 
we call it from the GUI for example. Though that might introduce much more 
complexity and discrepancy depending on which tool is used. Therefore probably 
not a good idea.

How we render a broken image in the GUI is something that can then be done 
almost any way we seem fit. It could be even something like "-1 (broken?)" in 
the Size column.





      reply	other threads:[~2023-08-22  9:42 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-14 11:10 Aaron Lauterer
2023-06-14 11:10 ` [pve-devel] [PATCH v2 manager 2/2] ui: ContentView: don't show size if it is -1 Aaron Lauterer
2023-07-18  7:26 ` [pve-devel] [PATCH v2 storage 1/2] rbd: improve handling of missing images Aaron Lauterer
2023-08-21 15:05 ` Fiona Ebner
2023-08-22  9:42   ` Aaron Lauterer [this message]

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=c5a08c77-992e-48b3-81e8-8e70a0c0136c@proxmox.com \
    --to=a.lauterer@proxmox.com \
    --cc=f.ebner@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal