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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 14B7DB47E for ; Fri, 29 Apr 2022 09:40:47 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 104A281AD for ; Fri, 29 Apr 2022 09:40:47 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 8D5AD81A2 for ; Fri, 29 Apr 2022 09:40:46 +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 6653242F82 for ; Fri, 29 Apr 2022 09:40:46 +0200 (CEST) Message-ID: <4d86c545-543f-38d3-11cb-6c4fabd70347@proxmox.com> Date: Fri, 29 Apr 2022 09:40:45 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:100.0) Gecko/20100101 Thunderbird/100.0 Content-Language: en-US To: Proxmox VE development discussion , Aaron Lauterer , Dominik Csapak References: <20220428115809.1661165-1-a.lauterer@proxmox.com> <20220428115809.1661165-6-a.lauterer@proxmox.com> <20f077cf-364a-9352-bf97-551a2955349d@proxmox.com> From: Thomas Lamprecht In-Reply-To: <20f077cf-364a-9352-bf97-551a2955349d@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.488 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 -2.93 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 Subject: Re: [pve-devel] [PATCH manager 5/5] ceph pools: allow to create erasure code pools 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: Fri, 29 Apr 2022 07:40:47 -0000 On 29.04.22 09:33, Aaron Lauterer wrote: > > On 4/28/22 16:32, Dominik Csapak wrote: >> is there a specific reason why you still force the autocreation >> of the storage? i don't mind really, but giving a reason >> would be nice. if there is no reason, i'd drop that since >> the user can specify it anyway and adding one manually >> should also not too hard.. > > I guess I could have been more explicit in the commit message. I decided to always create the storage config to have the coupling of ec pool and replicated metadata pool in place. We currently only have the RBD use case for EC pools in PVE itself and otherwise people might forget about it and any RBD image created without the data-pool parameter configured will be placed in the replicated pool. > IMO still confusing to enforce it, default to true can be Ok, but that's something different than hard-enforcing it always, would surely lead to a bug report sooner or later. Oh, and for the CLI I'd like to see this as separate command, i.e.: pveceph ec-pool create pveceph ec-pool destroy That can then have the expanded options format, which can be nicer to use on CLI, and also default to add-storage there already. small ot/general nit: can you please use a text-width of 80 (or even 100) cc on the mailing list, my MTA is configured to show text as is to ensure patches are seen correctly, so long replies require horizontal scrolling