From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id E89AA1FF16B for <inbox@lore.proxmox.com>; Thu, 20 Feb 2025 13:53:58 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B43C11163B; Thu, 20 Feb 2025 13:53:52 +0100 (CET) Message-ID: <d4c95f83-c329-446e-a56f-ca86e9c0e6d3@proxmox.com> Date: Thu, 20 Feb 2025 13:53:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Fiona Ebner <f.ebner@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20250211160825.254167-1-d.kral@proxmox.com> <20250211160825.254167-3-d.kral@proxmox.com> <da714d0b-c93b-4734-b91a-b6783bf1af49@proxmox.com> <13dd23d2-5a04-4ce2-b047-a93247ae0300@proxmox.com> <e79ce33b-effe-43b3-8c3d-0c767beacea7@proxmox.com> Content-Language: en-US From: Daniel Kral <d.kral@proxmox.com> In-Reply-To: <e79ce33b-effe-43b3-8c3d-0c767beacea7@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.009 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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 pve-storage v2 2/5] introduce helpers for content type assertions of storages and volumes 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> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> On 2/20/25 10:36, Fiona Ebner wrote: > Not necessarily? What about qm showcmd <ID>? Question is, do we want to > do storage-related checks there or not? If we already check for the > content type, I don't see much reason not to check for storage being > enabled either. > > It could be seen as surprising, because it's just building the command, > why would it do storage checks? But if we follow that rationale, it > shouldn't do either of the checks. > > I'm fine with keeping/adding the checks, because we already do that for > other things while building the command too. Otherwise, we'd need some > nocheck flag or similar. I have no strong opinion against that either. > Just nobody complained yet about this I guess and there's nothing really > wrong with having the semantics be getting a "checked" command. Right, there's also `qm showcmd`, I only thought about the vm_start_nolock case here! I guess the best thing would be to move it there, or would an extra iteration through the disks like in cfg2cmd be too expensive there? Otherwise I'll let it be in cfg2cmd. On 2/20/25 10:36, Fiona Ebner wrote: > It does seem natural that callers that check for a content type being > supported actually want to do something with that content type too and > actually care about the content type being "ready"/"available". The only > cases I would imagine is checks about the storage config whether it > would be supported in principle, but if we ever have one of those, we > just don't need to use the helper. Yes, I'd double check that when working on the v3, but as far as I've seen how they current have been used and going through the cases above it'd sound like they were used like this before anyway. _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel