Re: [pve-devel] [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API

[Florian Paul Azim Hoberg via pve-devel <pve-devel@lists.proxmox.com>]

[-- Attachment #1: Type: message/rfc822, Size: 17664 bytes --]

From: Florian Paul Azim Hoberg <florian.hoberg@credativ.de>
To: "pve-devel@lists.proxmox.com" <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH pve-manager 1/1] close: 6799: add apt upgrade path to PVE API
Date: Wed, 17 Sep 2025 10:26:34 +0000
Message-ID: <D1CC1A00-8AEB-4F67-AAFD-15363FC60A59@credativ.de>

Hey Thomas!


Thanks for the feedback and for taking the time to explain the reasoning.

Am 12.09.2025 um 11:22 schrieb Thomas Lamprecht <t.lamprecht@proxmox.com>:

Blindly upgrading can be dangerous and result in broken system, that's
why the Proxmox VE API only supports the interactive upgrade through
API using a html5 based shell to keep a (human) admin in the loop.

I do understand the concern about less experienced users and the potential risk of breaking a system through unattended upgrades. At the same time, I have a bit of a hard time fully seeing the reasoning here: the API already exposes very powerful and potentially destructive operations (like deleting a VM, removing storage, shutting down node(s)), which can also cause serious issues if used without proper understanding.

From my perspective, providing an API path for upgrades would simply allow those who know what they’re doing to automate their workflows in a cleaner way, without having to fall back to less direct methods (e.g. scripting around apt, HTML5 consoles, automating with Ansible or other lower-level tools). The responsibility for using such an API safely would still rest with the admin, just like with the other API endpoints and also doesn’t deprecate the current workflow. Instead, it would just add another option. Beside this, I honestly don’t really get the differences between:



Current / Console:
A user sees the pending packages that can be upgraded and clicks on upgrade. The HMTL5 console opens up including the upgrade command. At this point, the user sees the full package list and needs to confirm the upgrade process.

API:
An operator can fetch the list of pending packages that can be upgraded by the API and can decide on his own or by automated validations (white/blacklist, timing, dependencies etc.) to perform upgrades, which can be automatically called afterwards for each node without any further user/operator interaction.

Outcome:
In both ways, if an upgrade fails, a lesser experienced user runs into a problem which probably cannot be solved immediately. I don’t see huge differences, if those potential errors are now directly shown on a console or in a log file. Beside this, service related restarts, network changes (or even network card renaming [at least before pve9]) and many other reasons may cause additional issues and might detach a user from the html5 console.

In general, I think we can gain more benefits by adding such an API path where even third-party tools and automation stacks can simply use this to upgrade nodes in clusters based on their own abstracted logic without requiring any ssh access. Also, the Datacenter Manager could highly benefit from this: Right now, an Operator is required to have a direct connection to all (at least to the targeted) node(s) and clusters when being kicked to the node’s HMTL5 console for upgrading, while the Datacenter Manager already might have a network connectivity. For local clusters, this might still be easily solvable, but for clusters in different locations or even countries this might become a pain (where you especially want to separate the infrastructure and admin facing parts as much as possible).

So thanks for submitting a contribution, but we cannot accept this.

That said, I respect your position and appreciate the clarity of your response, and I hope you may reconsider this, independent of specific technical implementation details. Also, thank you for taking the time and efforts for the review!

Thanks,
Florian


[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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