Update notes¶

This section describes the specific actions you as a Cloud Operator need to complete to accurately plan and successfully perform your Mirantis OpenStack for Kubernetes (MOSK) cluster update to the version 25.1. Consider this information as a supplement to the generic update procedure published in Operations Guide: Update a MOSK cluster.

Cluster update schema¶

There is a possibility to update to the 25.1 version from the following cluster versions:

24.3 (released on October 16, 2024)
24.3.2 (released on February 03, 2025)

Important

Be advised that updating to version 25.1 will not be possible from at least the upcoming 24.3.3 and 24.3.4 patches. For the detailed cluster update schema, refer to Managed cluster update schema.

Update impact and maintenance windows planning¶

The following table provides details on the update impact on a MOSK cluster.

Impact during update to MOSK 25.1¶
Updated component	Impact on cloud users	Impact on cloud workloads
OpenStack and Tungsten Fabric	~1% of read operations on cloud API resources may fail ~8% of create and update operations on cloud API resources may fail	Open vSwitch networking - interruption of the North-South connectivity, depending on the type of virtual routers used by a workload: Distributed (DVR) routers - no interruption Non-distributed routers, High Availability (HA) mode - interruption up to 1 minute, usually less than 5 seconds Non-distributed routers, non-HA mode - interruption up to 10 minutes Tungsten Fabric networking - no impact
Ceph	~1% of read operations on object storage API may fail	IO performance degradation for Ceph-backed virtual storage devices. Pay special attention to the known issue 50566 that may affect the maintenance window.
Host OS components	No impact	Instance network connectivity interruption up to 5 minutes
Host OS kernel	No impact	Restart of instances due to the hypervisor reboot 0

0: Host operating system needs to be rebooted for the kernel update to be applied. Configure live-migration of workloads to avoid the impact on the instances running on a host.

Known issues during the update¶

Before updating the cluster, be sure to review the potential issues that may arise during the process and the recommended solutions to address them, as outlined in Update known issues.

Pre-update actions¶

Upgrade Ubuntu to 22.04¶

Since Ubuntu 20.04 reaches end-of-life in April 2025, MOSK 25.1 does not support the Cluster release update of the Ubuntu 20.04-based clusters, and Ubuntu 22.04 becomes the only supported version of the host operating system.

Therefore, ensure that all your MOSK clusters are running Ubuntu 22.04 to unblock update of the management cluster to the Cluster release 16.4.1. For the Ubuntu upgrade procedure, refer to Upgrade an operating system distribution.

Caution

Usage of third-party software, which is not part of Mirantis-supported configurations, for example, the use of custom DPDK modules, may block upgrade of an operating system distribution. Users are fully responsible for ensuring the compatibility of such custom components with the latest supported Ubuntu version.

Back up custom Grafana dashboards¶

In MOSK 25.1 and Container Cloud 2.29.0, Grafana is updated to version 11 where the following deprecated Angular-based plugins are automatically migrated to the React-based ones:

Graph (old) -> Time Series
Singlestat -> Stat
Stat (old) -> Stat
Table (old) -> Table
Worldmap -> Geomap

This migration may corrupt custom Grafana dashboards that have Angular-based panels. Therefore, if you have such dashboards, back them up and manually upgrade Angular-based panels before updating to MOSK 25.1 to prevent custom appearance issues after plugin migration.

Note

All Grafana dashboards provided by StackLight are also migrated to React automatically. For the list of default dashboards, see View Grafana dashboards.

Warning

For management clusters that are updated automatically, it is important to prepare the backup before Container Cloud 2.29.0 is released. Otherwise, custom dashboards using Angular-based plugins may be corrupted.

For managed clusters, you can perform the backup after the Container Cloud 2.29.0 release date but before updating them to MOSK 25.1.

Post-update actions¶

Hide sensitive ingress data for Ceph public endpoints¶

Since MOSK 25.1, you can hide ingress TLS certificates for Ceph Object Gateway public endpoint in a secret object and use tlsSecretRefName in the Ceph cluster spec. This configuration prevents exposing sensitive data of Ceph public endpoints.

On existing clusters, Mirantis recommends updating the Ceph cluster spec by replacing fields containing TLS certificates with tlsSecretRefName:

Obtain ingress details. For example:

kubectl get ingress -n rook-ceph

Example of system response:

NAME                                    CLASS    HOSTS                                 ADDRESS                                                                                                    PORTS     AGE
rook-ceph-rgw-<rgw-store-name>-ingress   <none>   <rgw-store-name>.<rgw-public-domain> 10.10.0.134,10.10.0.148,10.10.0.203,10.10.0.210,10.10.0.222,10.10.0.232,10.10.0.27,10.10.0.67,10.10.0.82   80, 443   70d

Obtain the TLS secret name:

kubectl get ingress -n rook-ceph rook-ceph-rgw-<rgw-store-name>-ingress -o jsonpath='{.spec.tls[0].secretName}'

On the management cluster, update the kaascephcluster spec:

Note

Since MOSK 25.1, the ingress field of the Ceph cluster spec is automatically replaced with the ingressConfig field.

Remove the cacert, tlsCert, and tlsKey fields:

spec:
  cephClusterSpec:
    ingressConfig:
      tlsConfig:
        publicDomain: public.domain.name
        cacert: |
          -----BEGIN CERTIFICATE-----
          ...
          -----END CERTIFICATE-----
        tlsCert: |
          -----BEGIN CERTIFICATE-----
          ...
          -----END CERTIFICATE-----
        tlsKey: |
          -----BEGIN RSA PRIVATE KEY-----
          ...
          -----END RSA PRIVATE KEY-----
      controllerClassName: <ingress-controller-class-name>
      ...

Add tlsSecretRefName with the previously obtained TLS secret name where TLS certificates are stored:

spec:
  cephClusterSpec:
    ingressConfig:
      tlsConfig:
        publicDomain: public.domain.name
        tlsSecretRefName: <secret-name>
      controllerClassName: <ingress-controller-class-name>
      ...

Caution

If you update the ingress certificate, the new secret must be base64-encoded and have the same format as in the previous secret.

Update the Alertmanager API v1 integrations to v2¶

Note

This step applies if you use the Alertmanager API v1 in your integrations and configurations. Otherwise, skip this step.

In MOSK 25.1 and Container Cloud 2.29.0, the Alertmanager API v1 is deprecated and will be removed in one of the upcomping MOSK and Container Cloud releases. For details, see Deprecation Notes.

Therefore, if you use API v1, update your integrations and configurations to use the API v2 ensuring compatibility with new versions of Alertmanager.

Update parameters for externalOutputs¶

Note

This step applies if log forwarding to external destinations is enabled. Otherwise, skip this step.

In the following major MOSK and Container Cloud releases, the Fluentd plugin out_elasticsearch will be updated to the version that no longer supports external output to opensearch.

Therefore, if you use opensearch as an external destination for logging and used the elasticsearch value for the logging.externalOutputs[].type parameter, change it to opensearch in the scope of Container Cloud 2.29.x and MOSK 25.1.x release series. For the configuration procedure, see Enable log forwarding to external destinations.

Update RabbitMQ monitoring utilities¶

MOSK 25.1 introduces several enhancements for monitoring of RabbitMQ by StackLight, which include deprecation of some RabbitMQ metrics, alerts, and dashboard. For details, see RabbitMQ monitoring rework.

If you use deprecated RabbitMQ metrics in customizations such as alerts and dashboards, switch to the new metrics and dashboards within the course of the MOSK 25.1 series to prevent issues once the deprecated metrics and dashboard will be removed.

Start using BareMetalHostInventory instead of BareMetalHost¶

MOSK 25.1 introduces the BareMetalHostInventory resource that must be used instead of BareMetalHost for adding and modifying configuration of bare metal servers. Therefore, if you need to modify an existing or create a new configuration of a bare metal host, use BareMetalHostInventory.

Each BareMetalHostInventory object is synchronized with an automatically created BareMetalHost object, which is now used for internal purposes of the Container Cloud private API.

Caution

Any change in the BareMetalHost object will be overwitten by BareMetalHostInventory.

For any existing BareMetalHost object, a BareMetalHostInventory object is created automatically during cluster update.

Caution

While the Cluster release of the management cluster is 16.4.0, BareMetalHostInventory operations are allowed to m:kaas@management-admin only. Once the management cluster is updated to the Cluster release 16.4.1 (or later), this limitation will be lifted.

Migrate container runtime from Docker to containerd¶

MOSK 25.1 introduces switching of the default container runtime for the underlying Kubernetes cluster from Docker to containerd on greenfield deployments.

On existing deployments, perform the mandatory migration from Docker to containerd in the scope of MOSK 25.1.x. Otherwise, the management cluster update to Container Cloud 2.30.0 will be blocked.

Important

Container runtime migration involves machine cordoning and draining.

Required action

Operations Guide: Migrate container runtime from Docker to containerd