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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 576FBB542 for <pve-devel@lists.proxmox.com>; Fri, 29 Apr 2022 11:27:42 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 474C69428 for <pve-devel@lists.proxmox.com>; Fri, 29 Apr 2022 11:27:12 +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 B2A91941A for <pve-devel@lists.proxmox.com>; Fri, 29 Apr 2022 11:27:11 +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 87CF942FFD for <pve-devel@lists.proxmox.com>; Fri, 29 Apr 2022 11:27:11 +0200 (CEST) Message-ID: <d214dd78-fc4c-6a5f-8d99-29da73bc64b5@proxmox.com> Date: Fri, 29 Apr 2022 11:27:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Thomas Lamprecht <t.lamprecht@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com> References: <20220428115809.1661165-1-a.lauterer@proxmox.com> <20220428115809.1661165-6-a.lauterer@proxmox.com> <c37678d4-bf87-8d2b-27bc-ef0bbbbd2fe6@proxmox.com> <20f077cf-364a-9352-bf97-551a2955349d@proxmox.com> <4d86c545-543f-38d3-11cb-6c4fabd70347@proxmox.com> From: Aaron Lauterer <a.lauterer@proxmox.com> In-Reply-To: <4d86c545-543f-38d3-11cb-6c4fabd70347@proxmox.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.466 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 <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, 29 Apr 2022 09:27:42 -0000 On 4/29/22 09:40, Thomas Lamprecht wrote: > 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. I am sending a follow up which makes it a default that can be explicitly set > > 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. Okay. One question on how to handle the destroy part. Since we do have 2 pools, depending on what the user provides, should we search for the storage name and any of the possible pool names and then figure out the missing pools from there and destroy both pools? This way, the user could provide us with any of the 3 possibilities. On the other hand, this could be unexpected behavior, and we may rather let the user destroy 2 pools. Or should it be the regular pool destroy, but set the parameters to destroy ec profiles? > > > 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 > Sorry for that. Should be fixed now :)