public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Thomas Lamprecht <t.lamprecht@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	Max Carrara <m.carrara@proxmox.com>,
	Wolfgang Bumiller <w.bumiller@proxmox.com>
Subject: Re: [pve-devel] [RFC v1 pve-storage 0/6] RFC: Tighter API Control for Storage Plugins
Date: Fri, 7 Feb 2025 08:17:15 +0100	[thread overview]
Message-ID: <5ca3fd52-5790-4f83-a85c-a95b9b1e6bca@proxmox.com> (raw)
In-Reply-To: <0183f296-f15a-423a-a6b2-47e8dbd9316f@proxmox.com>

Am 06.02.25 um 15:56 schrieb Fiona Ebner:
> There are no such strong reasons, but we didn't have such strong reasons
> last time either (IIRC changing snapshot parameter for export for btrfs
> or something like that). I thought we need to do that on any breaking
> change? We do have a few queued up already for the next reset. Hence my
> suggestion to do it for PVE 9 so plugin authors can adapt together with
> adapting for the new Debian release.

Yeah, last time caused some more fall-out than I expected, I have reduced
motivation to repeat that, especially as we grew quite a few more users
and also some new external storage plugins.

If nothing big comes up I'm fine with just keep increasing both VERSION
and AGE in lock-step as needed. If that becomes painful we should rework
our approach to be less sudden – we want short betas for $reasons, thus
plugin author do not get a long heads-up there at all – like e.g. using
a moving window to more gradually drop support for older versions, unlike
a full reset, ideally defining which will be removed already earlier (most
lenient would be a full major release, less might be fine, needs to be
thought out). We could use those two also to decide for what to warn and
for what to either output nothing or only very rarely some notice level log

We might also need to get a bit more strict with how we handle API breaks,
but as this is easier to adapt too as end-user are less likely to be
affected, as in, our UI still works, breakage happens normally at an
endpoint level instead of all or nothing like here with storage plugins,
which means likely breaking PVE interfacing with such storages completely,
which will not allow guests on those storages to run or backups to go
through, ...


_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2025-02-07  7:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-30 14:51 Max Carrara
2025-01-30 14:51 ` [pve-devel] [RFC v1 pve-storage 1/6] version: introduce PVE::Storage::Version Max Carrara
2025-02-05 11:20   ` Wolfgang Bumiller
2025-01-30 14:51 ` [pve-devel] [RFC v1 pve-storage 2/6] rework plugin loading and registration mechanism Max Carrara
2025-02-05 11:33   ` Wolfgang Bumiller
2025-01-30 14:51 ` [pve-devel] [RFC v1 pve-storage 3/6] introduce compile-time checks for prohibited sub overrides Max Carrara
2025-02-05 11:41   ` Wolfgang Bumiller
2025-02-05 11:55     ` Wolfgang Bumiller
2025-01-30 14:51 ` [pve-devel] [RFC v1 pve-storage 4/6] plugin: replace fixme comments for deprecated methods with attribute Max Carrara
2025-01-30 14:51 ` [pve-devel] [RFC v1 pve-storage 5/6] introduce check for `type` method and duplicate types Max Carrara
2025-01-30 14:51 ` [pve-devel] [RFC v1 pve-storage 6/6] introduce check for duplicate plugin properties Max Carrara
2025-02-05 11:17 ` [pve-devel] [RFC v1 pve-storage 0/6] RFC: Tighter API Control for Storage Plugins Wolfgang Bumiller
2025-02-05 15:20   ` Max Carrara
2025-02-06 14:05     ` Fiona Ebner
2025-02-06 14:39       ` Thomas Lamprecht
2025-02-06 14:56         ` Fiona Ebner
2025-02-07  7:17           ` Thomas Lamprecht [this message]
2025-02-07  9:59             ` Fiona Ebner
2025-02-07 11:57               ` Thomas Lamprecht
2025-02-07 15:25                 ` Fiona Ebner

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=5ca3fd52-5790-4f83-a85c-a95b9b1e6bca@proxmox.com \
    --to=t.lamprecht@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=m.carrara@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=w.bumiller@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