Am 19.01.26 um 5:54 PM schrieb Daniel Kral: > On Mon Jan 19, 2026 at 4:00 PM CET, Fiona Ebner wrote: >> Am 15.12.25 um 4:54 PM schrieb Daniel Kral: >>> Signed-off-by: Daniel Kral <[email protected]> >>> --- >>> Needs a version bump for pve-ha-manager. >>> >> >> Such a bump is only required in the sense that the enum variant cannot >> actually happen before new ha-manager is installed. The patch here could >> be applied without such a bump, upgraded and nothing would break. >> >> But technically, it's a breaking change in the other direction. New HA >> manager might cause old qemu-server to return something that was not >> declared in the return schema. I guess it won't be a huge issue in >> practice though. API clients already need to be prepared for new >> variants being returned and the issue would only manifest if the API >> client checks the correctness of the result against the installed, old >> qemu-server API schema. > > Well this threw me in an unexpected rabbit hole ;) > > I only added the bump here because I noticed that we do check the > correctness of the return value of the API handler at the CLI (e.g. if > `ha-manager migrate vm:100 node1` returns 'node-affinity' as a blocking > cause), then it will fail > > ``` > # ha-manager migrate vm:100 node1 > 400 Result verification failed > blocking-resources[0].cause: value 'node-affinity' does not have a value in > the enumeration 'resource-affinity' > ha-manager crm-command migrate <sid> <node> > ``` > > and indeed we verify the result at every CLI invocation [0] (the third > parameter toggles result verification in [1]). > > One could enable result verification on a case-by-case basis when > calling the API method directly via the package (e.g. > PVE::API2::Example->method({ param: "something"}, 1)) [2], but otherwise > we do not validate the response with pvesh nor the HTTP server [3] [4] > [5], so this is indeed fine without as bump!
What you are describing here is the breaking change in the other direction: new ha-manager breaks qemu-server without this patch when result verification is used. The bump would technically still not be needed even if we used result verification everywhere: new qemu-server extends the schema but is completely fine with old ha-manager, it's just that the new variant cannot happen then. > > Sorry for going off on a tangent here, I was curious where that > happened. That's perfectly fine :) > > [0] > https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/RESTHandler.pm;h=cc82fe8df56a429d64094209d264621de3d4e89e;hb=refs/heads/master#l1019 > [1] > https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/RESTHandler.pm;h=cc82fe8df56a429d64094209d264621de3d4e89e;hb=refs/heads/master#l486 > [2] > https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/RESTHandler.pm;h=cc82fe8df56a429d64094209d264621de3d4e89e;hb=refs/heads/master#l340 > [3] > https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/RESTHandler.pm;h=cc82fe8df56a429d64094209d264621de3d4e89e;hb=refs/heads/master#l232 > [4] > https://git.proxmox.com/?p=pve-common.git;a=blob;f=src/PVE/RESTHandler.pm;h=cc82fe8df56a429d64094209d264621de3d4e89e;hb=refs/heads/master#l413 > [5] > https://git.proxmox.com/?p=pve-manager.git;a=blob;f=PVE/HTTPServer.pm;h=bb8052e3b428f9b8d11d63f7c7e9d45f40344dca;hb=HEAD#l192 > >> >>> src/PVE/API2/Qemu.pm | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/src/PVE/API2/Qemu.pm b/src/PVE/API2/Qemu.pm >>> index 190878de..5c4f6eb3 100644 >>> --- a/src/PVE/API2/Qemu.pm >>> +++ b/src/PVE/API2/Qemu.pm >>> @@ -5196,7 +5196,7 @@ __PACKAGE__->register_method({ >>> type => 'string', >>> description => "The reason why the HA" >>> . " resource is blocking the >>> migration.", >>> - enum => ['resource-affinity'], >>> + enum => ['node-affinity', >>> 'resource-affinity'], >>> }, >>> }, >>> }, > _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
