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 EFD13647B9 for ; Fri, 28 Jan 2022 10:22:49 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id E2F682C790 for ; Fri, 28 Jan 2022 10:22:49 +0100 (CET) Received: from mx.antreich.com (mx.antreich.com [173.249.42.230]) (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 id 6D4CB2C787 for ; Fri, 28 Jan 2022 10:22:49 +0100 (CET) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antreich.com; s=2018; t=1643361727; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uoZ+aGGmtKXVEhNLmBOSut0MJxAI9Nh+GfiCOfWrODs=; b=YsSVMAfcuwxueOvWgUprTb2rtsYbnO+YZTYWksAu+yIu/oNOrH4qRfBEx3DhHp73eSjpBX kjT8FJN67qvlFJs4VjFbVrkHXrLmpOsZZuusj/hxmNbb3Bf7F2MGJXvh29KMqIc2s1lVlL fjBTABYuHZsnc6hD3rGvIyek33qdeFgTIj5ElC4usL+Wwf9jD6Wr6YyZ7H1HS0yAXtaly4 +ixRi6FK+iI2xZrF2lObO77Rx84s1wxSmQuuUgABNnai09ZUD/6EDKsx3L/sFvN5ZBd2bv o944MOTr4Z3kYo5DaABfIQpR4nn08OG24/yaP4SdDoLGW22ykabxkIy1Jmmywg== Date: Fri, 28 Jan 2022 09:22:08 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Alwin Antreich" Message-ID: To: "Thomas Lamprecht" , "Proxmox VE development discussion" , "Aaron Lauterer" In-Reply-To: <51d6f7da-3163-2fe4-05a3-dc63226088e0@proxmox.com> References: <51d6f7da-3163-2fe4-05a3-dc63226088e0@proxmox.com> <1ae1d772-c466-5694-cf77-4018aedddafc@proxmox.com> <20220126160734.2868618-1-a.lauterer@proxmox.com> <3dbb90bb8bfec2db7a08965c0301480f@antreich.com> <00b53f8566061be26bdf770332245ea9@antreich.com> <0e3081d0-3d09-798a-e4d2-209db646ae75@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.385 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain SPF_HELO_PASS -0.001 SPF: HELO matches SPF record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [antreich.com] Subject: Re: [pve-devel] [PATCH storage] rbd: add support for erasure coded ec 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, 28 Jan 2022 09:22:50 -0000 January 28, 2022 6:50 AM, "Thomas Lamprecht" wr= ote: > On 27.01.22 17:28, Aaron Lauterer wrote: >=20 >>=20Besides the whole "where to store the data-pool parameter" issue, ha= ving custom client configs per >> storage would most likely be its own feature request. Basically extend= ing the current way to >> hyperconverged storages. Though that would mean some kind of config me= rging as the hyperconverged >> situation relies heavily on the default Ceph config file. >> I still see the custom config file as an option for the admin to add c= ustom options, not to spread >> the PVE managed settings when it can be avoided. >=20 >=20Yeah config merging would be probably nicer if avoided, and we can ad= d a > `ceph-opt` like format-string property that allows access to most of th= e > more relevant settings if demand comes up. K. Would you guys have any objection, when I send a docs patch to document t= he current client conf possibility, under /etc/pve/priv/ceph/.co= nf? Or rather document it for /etc/pve/ceph.conf? @Aaron, or is it counter productive to what you try to do? > Anyhow, thanks to both of you for the constructive discussion, always > appreciated. :) Cheers, Alwin