public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Aaron Lauterer <a.lauterer@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager 5/6] ui: osd: warn if removal could be problematic
Date: Thu, 24 Feb 2022 13:46:41 +0100	[thread overview]
Message-ID: <ead5d0a9-7a55-7c88-aae5-c8ee077a2fca@proxmox.com> (raw)
In-Reply-To: <20220218113827.1415641-6-a.lauterer@proxmox.com>

On 18.02.22 12:38, Aaron Lauterer wrote:
> If an OSD is removed during the wrong conditions, it could lead to
> blocked IO or worst case data loss.
> 
> Check against global flags that limit the capabilities of Ceph to heal
> itself (norebalance, norecover, noout) and if there are degraded
> objects.
> 
> Unfortunately, the 'safe-to-destroy' API endpoint will not help here as
> it only works as long as the OSD is still running. By the time the
> destroy button is enabled, the OSD needs to be stopped.
> 
> Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
> ---
> After the short discussion on the previous version [0] and the hints to
> ok-to-stop & safe-to-destroy I kept the original approach with the
> reason given in the commit message.
> 
> But now the checks are run before opening the window and showing a
> loading screen.
> 
> [0] https://lists.proxmox.com/pipermail/pve-devel/2022-February/051597.html
> 
>  www/manager6/ceph/OSD.js | 66 +++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 65 insertions(+), 1 deletion(-)
> 
> diff --git a/www/manager6/ceph/OSD.js b/www/manager6/ceph/OSD.js
> index e126f8d0..27f56760 100644
> --- a/www/manager6/ceph/OSD.js
> +++ b/www/manager6/ceph/OSD.js
> @@ -178,6 +178,20 @@ Ext.define('PVE.CephRemoveOsd', {
>  	    labelWidth: 130,
>  	    fieldLabel: gettext('Cleanup Disks'),
>  	},
> +	{
> +	    xtype: 'displayfield',
> +	    name: 'osd-flag-hint',
> +	    userCls: 'pmx-hint',
> +	    value: gettext('Global flags limiting the self healing of Ceph are enabled.'),
> +	    hidden: true,
> +	},
> +	{
> +	    xtype: 'displayfield',
> +	    name: 'degraded-objects-hint',
> +	    userCls: 'pmx-hint',
> +	    value: gettext('Objects are degraded. Consider waiting until the cluster is healthy.'),
> +	    hidden: true,
> +	},
>      ],
>      initComponent: function() {
>          let me = this;
> @@ -198,6 +212,13 @@ Ext.define('PVE.CephRemoveOsd', {
>          });
>  
>          me.callParent();
> +
> +	if (me.warnings.flags) {
> +	    me.down('field[name=osd-flag-hint]').setHidden(false);
> +	}
> +	if (me.warnings.degraded) {
> +	    me.down('field[name=degraded-objects-hint]').setHidden(false);
> +	}
>      },
>  });
>  
> @@ -434,12 +455,55 @@ Ext.define('PVE.node.CephOsdTree', {
>  	    }).show();
>  	},
>  
> -	destroy_osd: function() {
> +	destroy_osd: async function() {
>  	    let me = this;
>  	    let vm = this.getViewModel();
> +
> +	    let warnings = {
> +		flags: false,
> +		degraded: false,
> +	    };
> +
> +	    let flagsPromise = Proxmox.Async.api2({
> +		url: `/cluster/ceph/flags`,
> +		method: 'GET',
> +	    });
> +
> +	    let statusPromise = Proxmox.Async.api2({
> +		url: `/cluster/ceph/status`,
> +		method: 'GET',
> +	    });
> +
> +	    me.getView().mask(gettext('Please wait...'));

'Loading...' is used by ExtJS, well, loading mask; I'd use the same here


> +
> +	    try {
> +		let result = await Promise.all([flagsPromise, statusPromise]);
> +
> +		let flagsData = result[0].result.data;
> +		let statusData = result[1].result.data;

one could deconstruct this directly, but it gets rather noisy:

let [ { result: { data: flagsData } }, { result: { data: statusData } } ] = await Promise.all(...);

meh...

> +
> +		let flags = Array.from(
> +		    flagsData.filter(v => v.value),
> +		    v => v.name,
> +		).filter(v => ['norebalance', 'norecover', 'noout'].includes(v));
> +
> +		if (flags.length) {
> +		    warnings.flags = true;
> +		}
> +		if (Object.keys(statusData.pgmap).includes('degraded_objects')) {
> +		    warnings.degraded = true;
> +		}
> +	    } catch (error) {
> +		Ext.Msg.alert(gettext('Error'), error.htmlStatus);
> +		me.getView().unmask();
> +		return;
> +	    }
> +
> +	    me.getView().unmask();
>  	    Ext.create('PVE.CephRemoveOsd', {
>  		nodename: vm.get('osdhost'),
>  		osdid: vm.get('osdid'),
> +		warnings: warnings,
>  		taskDone: () => { me.reload(); },
>  	    }).show();

we normally set `autoShow: true` instead for new additions of such window instances.

>  	},





  reply	other threads:[~2022-02-24 12:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-18 11:38 [pve-devel] [PATCH librados2-perl manager 0/6] Add Ceph safety checks Aaron Lauterer
2022-02-18 11:38 ` [pve-devel] [PATCH librados2-perl 1/6] mon_command: free outs buffer Aaron Lauterer
2022-02-21 15:35   ` Thomas Lamprecht
2022-02-18 11:38 ` [pve-devel] [PATCH librados2-perl 2/6] mon_command: optionally ignore errors and return hashmap Aaron Lauterer
2022-02-21 15:44   ` Thomas Lamprecht
2022-02-22 12:42     ` Aaron Lauterer
2022-02-18 11:38 ` [pve-devel] [PATCH manager 3/6] api: osd: force mon_command to scalar context Aaron Lauterer
2022-02-18 11:38 ` [pve-devel] [PATCH manager 4/6] api: mon: mds: osd: add safety check endpoints Aaron Lauterer
2022-02-22  8:44   ` Thomas Lamprecht
2022-03-14 16:49     ` Aaron Lauterer
2022-03-14 17:02       ` Thomas Lamprecht
2022-02-18 11:38 ` [pve-devel] [PATCH manager 5/6] ui: osd: warn if removal could be problematic Aaron Lauterer
2022-02-24 12:46   ` Thomas Lamprecht [this message]
2022-02-18 11:38 ` [pve-devel] [PATCH manager 6/6] ui: osd: mon: mds: warn if stop/destroy actions are problematic Aaron Lauterer

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=ead5d0a9-7a55-7c88-aae5-c8ee077a2fca@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=a.lauterer@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