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 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.
All configuration files are backward compatible to version 2.3.0. Note that in order to make use of the new viewer component, permissions must be configured in the CR definition. Also note that display secrets are automatically created unless explicitly disabled.
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.
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.