From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <a.lauterer@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) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 0656E73BFC for <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 17:57:02 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E370B279DB for <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 17:56:31 +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) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 780FD279CD for <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 17:56:27 +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 1E86845AFE for <pve-devel@lists.proxmox.com>; Fri, 16 Apr 2021 17:56:27 +0200 (CEST) To: Thomas Lamprecht <t.lamprecht@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> <86b079a3-9bb3-21ae-2dda-95069e5e7a4c@proxmox.com> From: Aaron Lauterer <a.lauterer@proxmox.com> Message-ID: <ce202f1c-22e5-bfa8-c992-c866811be832@proxmox.com> Date: Fri, 16 Apr 2021 17:56:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <86b079a3-9bb3-21ae-2dda-95069e5e7a4c@proxmox.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.010 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:57:02 -0000 On 4/16/21 5:48 PM, Thomas Lamprecht wrote: > 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. Okay, good to know. So I guess I will send a v2 of this patch and put more back-end checks (pool and namespace can be accessed/seen) on my todo list in combination with the possibility to pass the auth key for external RBD pools directly at creation time.