From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 B78947CB34 for ; Tue, 19 Jul 2022 08:51:16 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id AAF6425C56 for ; Tue, 19 Jul 2022 08:51:16 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (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 for ; Tue, 19 Jul 2022 08:51:14 +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 BA58F4207A for ; Tue, 19 Jul 2022 08:51:14 +0200 (CEST) Message-ID: Date: Tue, 19 Jul 2022 08:50:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: Stefan Hrdlicka , Proxmox VE development discussion References: <20220622143929.2757681-1-s.hrdlicka@proxmox.com> <20220622143929.2757681-2-s.hrdlicka@proxmox.com> <2cd2d083-e312-fd54-e77d-782bce413192@proxmox.com> <779a3434-e2a9-c92a-56b1-625346dcf1d4@proxmox.com> From: Fabian Ebner In-Reply-To: <779a3434-e2a9-c92a-56b1-625346dcf1d4@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.042 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% 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) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [wikipedia.org] Subject: Re: [pve-devel] [PATCH V2 manager 1/3] fix #2822: add iscsi, lvm, lvmthin & zfs storage for all cluster nodes X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2022 06:51:16 -0000 Am 18.07.22 um 16:33 schrieb Stefan Hrdlicka: > Servus Fabian, > > wenn ich die automatische Node Einschränkung weg nehme. Dann müsste ich > vermutlich etwas im Perl code anpassen, da ich sonst einen Fehler > bekomme wenn ich versuche neue Storages auf anderen Nodes hinzufügen. Da > er dann überprüft ob das Storage auch verfügbar ist/existiert. Das ist > z.B. bei ZFS oder LVMThin ist der Fall. > > Was sagst du denn dazu? > Please always post such discussions about patches/development to the developer list, so others can see it too ;) Also, please use https://en.wikipedia.org/wiki/Posting_style#Interleaved_style For non-German speakers: Stefan is concerned that users will run into errors when the node is not automatically restricted. Well, it actually *is* an error if the storage is configured for all nodes and not available on the current (i.e. from where it's added) node. But you do have a point of course, because why would a user even change the node to scan, if the storage is already available on the current node. I'd still rather not change the default restriction behavior (see below). Maybe we should just auto-restrict if the user actively changed the node to scan? > grüße Stefan > > > On 6/28/22 12:33, Fabian Ebner wrote: >> Am 22.06.22 um 16:39 schrieb Stefan Hrdlicka: >>> This adds a dropdown box for iSCSI, LVM, LVMThin & ZFS storage >>> options where a >>> cluster node needs to be chosen. As default the current node is >>> selected. It restricts the the storage to be only availabe on the >>> selected node. >> >> I don't think we should change the default restriction, especially for >> iSCSI and (shared) LVM, but also for local ones, as in many cases, >> cluster nodes will be set-up with similar storage and the new default >> might trip up some people. >> >>>