From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id B3A7873D26 for <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 17:49:13 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A0CB527955 for <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 17:48:43 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [212.186.127.180]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 3F0A327947 for <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 17:48:39 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 0574945AF0 for <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 17:48:39 +0200 (CEST) Message-ID: <86b079a3-9bb3-21ae-2dda-95069e5e7a4c@proxmox.com> Date: Fri, 16 Apr 2021 17:48:38 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:88.0) Gecko/20100101 Thunderbird/88.0 Content-Language: en-US To: Aaron Lauterer <a.lauterer@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20210416141026.19499-1-a.lauterer@proxmox.com> <90633710-e22f-66dc-2e77-9e8d6979a4ec@proxmox.com> <70e563f9-660f-8e70-f366-a73e3c55837f@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <70e563f9-660f-8e70-f366-a73e3c55837f@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.040 Adjusted score from AWL reputation of From: address KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] [PATCH manager] ui: RBDStorage: add field for RBD namespace X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Fri, 16 Apr 2021 15:49:13 -0000 On 16.04.21 17:39, Aaron Lauterer wrote: > Thx for the feedback and yep, I forgot to run the linter... > there's to much noise still in it for this repo, so totally understandable. > Anything against doing it via `rbd -p pool namespace ls`? AFAICT there is no > lightweight command to list namespaces via `rados`. Only thing I found was > listing all objects in the pool and fetching used namespaces from that > output: `rados -p rbd ls --format json` but that is an expensive operation. I mean, this is not a frequent operation, so we could ignore the overhead of fork + exec. So yes, I would accept that. If we find something more efficient it could always get replaced by that transparently any way. > One thing though that we should consider: so far adding an external RBD > storage worked even if the auth keyring wasn't present. The storage would > not get activated until the keyring file was present. But one could still do > that after adding the storage config. With this check we would make it a > requirement to first place the keyring file and then add the storage config. Actually, I requested the feature to be able to add one through the storage add and update API/web-interface a long time ago from Alwin, was lost in the cogs of time though... So; I do not see that as issue but rather as another small feature we could finally do. Handling in the backend should be similar to other secrets, e.g., pbs password or encryption-key, cifs password, etc.