From: Aaron Lauterer <a.lauterer@proxmox.com>
To: Alwin Antreich <alwin@antreich.com>,
Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH storage] rbd: add support for erasure coded ec pools
Date: Fri, 28 Jan 2022 10:50:56 +0100 [thread overview]
Message-ID: <01a32358-484e-1c8b-61c9-e03b9df5dbae@proxmox.com> (raw)
In-Reply-To: <e9599ab5c1cf527c41362429625aba53@antreich.com>
On 1/28/22 10:22, Alwin Antreich wrote:
> January 28, 2022 6:50 AM, "Thomas Lamprecht" <t.lamprecht@proxmox.com> wrote:
>
>> On 27.01.22 17:28, Aaron Lauterer wrote:
>>
>>> Besides the whole "where to store the data-pool parameter" issue, having custom client configs per
>>> storage would most likely be its own feature request. Basically extending the current way to
>>> hyperconverged storages. Though that would mean some kind of config merging 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 custom options, not to spread
>>> the PVE managed settings when it can be avoided.
>>
>> Yeah config merging would be probably nicer if avoided, and we can add a
>> `ceph-opt` like format-string property that allows access to most of the
>> more relevant settings if demand comes up.
> K.
>
> Would you guys have any objection, when I send a docs patch to document the current client conf possibility, under /etc/pve/priv/ceph/<storage>.conf? Or rather document it for /etc/pve/ceph.conf?
What exactly do you mean? How to add custom config options for external cluster (/etc/pve/priv/ceph/<storeid>.conf) and locally in the /etc/pve/ceph.conf AKA /etc/ceph/ceph.conf?
Sure, AFAICS the custom <storeid>.conf has been added in 2016 [0]. I did a quick search in the admin guide and did not find anything about it.
[0] https://git.proxmox.com/?p=pve-storage.git;a=commit;h=1341722
>
> @Aaron, or is it counter productive to what you try to do?
Right now, I am only working out the EC pools (data-pool) parameter. Having the current possibilities documented is surely a good idea.
Out of curiosity, do you have to use the custom configs often?
>
>> Anyhow, thanks to both of you for the constructive discussion, always
>> appreciated.
> :)
>
> Cheers,
> Alwin
>
next prev parent reply other threads:[~2022-01-28 9:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-26 16:07 Aaron Lauterer
2022-01-26 18:30 ` Alwin Antreich
2022-01-27 11:27 ` Aaron Lauterer
2022-01-27 15:41 ` Alwin Antreich
2022-01-27 16:28 ` Aaron Lauterer
2022-01-28 5:50 ` Thomas Lamprecht
2022-01-28 9:22 ` Alwin Antreich
2022-01-28 9:50 ` Aaron Lauterer [this message]
2022-01-28 10:54 ` Alwin Antreich
2022-01-28 11:21 ` Aaron Lauterer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01a32358-484e-1c8b-61c9-e03b9df5dbae@proxmox.com \
--to=a.lauterer@proxmox.com \
--cc=alwin@antreich.com \
--cc=pve-devel@lists.proxmox.com \
--cc=t.lamprecht@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.