From: "Fabian Grünbichler" <f.gruenbichler@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 1/2] api: return UPID in template call
Date: Fri, 10 Sep 2021 12:03:04 +0200 [thread overview]
Message-ID: <1631266387.dgh383fo0f.astroid@nora.none> (raw)
In-Reply-To: <53d4b135-8a72-a74a-1633-829f9826e0a1@proxmox.com>
On September 10, 2021 11:26 am, Dominik Csapak wrote:
> Isn't this technically a breaking api change?
>
> I.e. if someone relies on the '{data:null}' return for a successfull
> template task start, it would now break?
>
> Not that i'm opposed to the patch (on the contrary), just wanted
> to clarify
technically yes, in the same way that adding new fields to a return type
might trip up a very strict client implementation, and we do that all
the time ;)
the alternative would be to opt-into the new return type via an optional
parameter, but that just seems ugly (we don't enforce the return schema,
so we can have an API endpoint return null or the UPID if we want based
on whatever condition).
IMHO the fallout risk is minimal, the benefit is there, and not
returning it in the first place was a bug.
next prev parent reply other threads:[~2021-09-10 10:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-10 7:48 Fabian Grünbichler
2021-09-10 7:48 ` [pve-devel] [PATCH qemu-server 2/2] api: template: invert lock and fork Fabian Grünbichler
2021-10-04 7:46 ` [pve-devel] applied: " Thomas Lamprecht
2021-09-10 8:32 ` [pve-devel] [PATCH qemu-server 1/2] api: return UPID in template call Fabian Ebner
2021-09-10 10:03 ` Fabian Grünbichler
2021-09-10 9:26 ` Dominik Csapak
2021-09-10 10:00 ` Thomas Lamprecht
2021-09-10 10:03 ` Fabian Grünbichler [this message]
2021-10-04 7:46 ` [pve-devel] applied: " Thomas Lamprecht
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=1631266387.dgh383fo0f.astroid@nora.none \
--to=f.gruenbichler@proxmox.com \
--cc=d.csapak@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