mnl/VM-Operator
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 4 Wiki Activity Actions

Remove no longer needed sub-directory.

Browse source
This commit is contained in:
Michael Lipp 2025-03-03 10:16:05 +01:00
parent c004265f5e
commit cc78c38efe
23 changed files with 15 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

78
webpages/upgrading.md Normal file
View file

@ -0,0 +1,78 @@
---
title: "VM-Operator: Upgrading — Issues to watch out for"
description: >-
Information about issues to watch out for when upgrading the VM-Operator.
layout: vm-operator
---
# Upgrading
## To version 4.0.0
* The VmViewer conlet has been renamed to VmAccess. This affects the
[configuration](https://jdrupes.org/vm-operator/user-gui.html). Configuration
information using the old path
`/Manager/GuiHttpServer/ConsoleWeblet/WebConsole/ComponentCollector/VmViewer`
is still accepted for backward compatibility until the next major version,
but should be updated.
The change of name also causes conlets added to the overview page by
users to "disappear" from the GUI. They have to be re-added.
The latter behavior also applies to the VmConlet conlet which has been
renamed to VmMgmt.
* The configuration property `passwordValidity` has been moved from component
`/Manager/Controller/DisplaySecretMonitor` to
`/Manager/Controller/Reconciler/DisplaySecretReconciler`. The old path is
still accepted for backward compatibility until the next major version,
but should be updated.
* The standard [template](./runner.html#stand-alone-configuration) used
to generate the QEMU command has been updated. Unless you have enabled
automatic updates of the template in the VM definition, you have to
update the template manually. If you're using your own template, you
have to add a virtual serial port (see the git history of the standard
template for the required addition).
## To version 3.4.0
Starting with this version, the VM-Operator no longer uses a stateful set
with replica set to 1 to (indirectly) start the pod with the VM. Rather
it creates the pod directly. This implies that the PVCs must also be created
by the VM-Operator, which needs additional permissions to do so (update of
`deploy/vmop-role.yaml). As it would be ridiculous to keep the naming scheme
used by the stateful set when generating PVCs, the VM-Operator uses a
[different pattern](controller.html#defining-disks) for creating new PVCs.
The change is backward compatible:
* Running pods created by a stateful set are left alone until stopped.
Only then will the stateful set be removed.
* The VM-Operator looks for existing PVCs generated by a stateful
set in the pre 3.4 versions (naming pattern "*name*-disk-*vmName*-0")
and reuses them. Only new PVCs are generated using the new pattern.
## To version 3.0.0
All configuration files are backward compatible to version 2.3.0.
Note that in order to make use of the new viewer component,
[permissions](https://mnlipp.github.io/VM-Operator/user-gui.html#control-access-to-vms)
must be configured in the CR definition. Also note that
[display secrets](https://mnlipp.github.io/VM-Operator/user-gui.html#securing-access)
are automatically created unless explicitly disabled.
## To version 2.3.0
Starting with version 2.3.0, the web GUI uses a login conlet that
supports OIDC providers. This effects the configuration of the
web GUI components.
## To version 2.2.0
Version 2.2.0 sets the stateful set's `.spec.updateStrategy.type` to
"OnDelete". This fails for no apparent reason if a definition of
the stateful set with the default value "RollingUpdate" already exists.
In order to fix this, either the stateful set or the complete VM definition
must be deleted and the manager must be restarted.