--- Begin Message ---
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 <[email protected]>:
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
--- End Message ---
_______________________________________________
pve-devel mailing list
[email protected]
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
