From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 9B91F1FF146 for ; Tue, 07 Jul 2026 15:04:29 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id BE6DF2143F; Tue, 07 Jul 2026 15:04:28 +0200 (CEST) Message-ID: <3313628c-bee9-48c1-b0a3-326399b17c8c@proxmox.com> Date: Tue, 7 Jul 2026 15:04:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [PATCH v2 storage,cluster,manager 0/13] multipath: cluster-wide config, storage and health overview To: Thomas Lamprecht , pve-devel@lists.proxmox.com References: <20260703124707.1172980-2-t.lamprecht@proxmox.com> Content-Language: en-US From: Dominik Csapak In-Reply-To: <20260703124707.1172980-2-t.lamprecht@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783429457886 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.065 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: WPPEBJ46BRC7AKHDUOSQHT2CUMDUX3DJ X-Message-ID-Hash: WPPEBJ46BRC7AKHDUOSQHT2CUMDUX3DJ X-MailFrom: d.csapak@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: had a look over the code (a bit) and that looked fine (see the nits/comments on the individual patches). but wanted to give a bit more high level feedback (mostly UI) here: as dietmar already mentioned this kind of interface could be confusing when we have NVMEoF support as that normally does not use multipath also the split view of multipath (datacenter/node) is a pattern we don't often use (we do for e.g. ZFS replication/ceph though) and it has some limitations (not seeing every detail in the cluster overview) that could be overcome with a different approach: we could (similarly to how the pci mapping does it) have a global grid/tree/etc. that loads the status from the individual nodes via the api, and injects that status in the grid/tree that way we could still have full details in a global overview, and probably would not need the kv cache for the cluster at all (except if we want to keep that for api consumers, which would be understandable) this is a pattern i'd like to use a bit more, since it gives us the possibility to * reuse the node local api calls * have a 'cheap' global view that still shows details * does not prevent us to still show a node local variant if we don't want to do something like this, a short link from the global to local view would be good at least. Other than that, I'd find it better if one would not have to look up the wwid themselves, but if we had a view of 'remote disks' (e.g. fc, iscsi, nvme-o-f) somewhere that we could 'add into' multipath. With that we could even warn/forbid adding nvme disks to it at all. (I'd filter out true local disks, if we can detect that...) Also, I mentioned it in the patch specific feedback but i wanted to highlight it here: having a dynamic number of columns doesn't strike me as a very good pattern, especially if there can be many, so having the nodes as columns feels wrong to me... what do you think?