public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Maximiliano Sandoval <m.sandoval@proxmox.com>
Cc: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Dominik Csapak <d.csapak@proxmox.com>
Subject: Re: [pve-devel] [PATCH manager 1/2] ceph: remove global pg bits setting
Date: Wed, 20 Sep 2023 16:27:07 +0200	[thread overview]
Message-ID: <f98a361f-6a8b-4a7e-9660-ec50c3b5f728@proxmox.com> (raw)
In-Reply-To: <s8ojzslx75d.fsf@proxmox.com>

Am 20/09/2023 um 15:42 schrieb Maximiliano Sandoval:
> Thomas Lamprecht <t.lamprecht@proxmox.com> writes:
> 
>> @maximiliano: how does ceph react if oe sets this currently?
>> I.e., does it silently accepts unknown config keys, or does it break
>> something?
> 
> Running
> 
>     ceph config set global osd_pg_bits 42
> 
> results in
> 
>     Error EINVAL: unrecognized config option 'osd_pg_bits'
> 
> Having them set on /etc/pve/ceph.conf on the other hand does not throw
> any kind of warning as far as I can tell, but I suspect it does not do
> anything either.

Meh, as we do the latter it means that cephs will eat that value and
just ignore it, so this is a question about how strict we want to keep
the API "unbroken".

Dominik is def. right that just removing the parameter from our API
would be a breaking change in the technically correct sense.

But, AFAICT, this was never exposed via the pveceph CLI command nor the
web UI, so it's not that far-fetched to assume that it has close to zero
use in the wild, but we surely cannot be certain about that (some user
might have added it to their automatic provision script and us remove it
the param now would suddenly cause that to fail after the upgrade).

> Please tell if I am missing something or if I should do a new version of
> the patch.

While I'm not a favor of keeping things around that (Very Highly
Probably™) nobody will miss anyway, here just keeping the parameter is
simply way too cheap to not do that. So, let's not go for my normal
route of ripping it out and see if somebody complains once it hits
no-subscription, to then react accordingly.

In summary, yes, please send a new version of this patch that keeps a
(reduced) "pg_bits" API parameter, drops setting the value (as that is a
NO-OP anyway) and maybe even adds a warning like:
"the 'pg_bits' is deprecated and will be removed in the future"





      reply	other threads:[~2023-09-20 14:27 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-07  9:49 Maximiliano Sandoval
2023-09-07  9:49 ` [pve-devel] [PATCH manager 2/2] ceph: api: use snake_case when setting options Maximiliano Sandoval
2023-09-20 12:10 ` [pve-devel] [PATCH manager 1/2] ceph: remove global pg bits setting Dominik Csapak
2023-09-20 13:21   ` Thomas Lamprecht
2023-09-20 13:42     ` Maximiliano Sandoval
2023-09-20 14:27       ` Thomas Lamprecht [this message]

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=f98a361f-6a8b-4a7e-9660-ec50c3b5f728@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=m.sandoval@proxmox.com \
    --cc=pve-devel@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal