Mirantis Container Cloud (MCC) becomes part of Mirantis OpenStack for Kubernetes (MOSK)!

Starting with MOSK 25.2, the MOSK documentation set covers all product layers, including MOSK management (formerly Container Cloud). This means everything you need is in one place. Some legacy names may remain in the code and documentation and will be updated in future releases. The separate Container Cloud documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

Update notes

This section describes the specific actions you need to complete to accurately plan and successfully perform the update. Consider this information as a supplement to the generic update procedures published in Operations Guide: Update to a patch version.

Cluster update schema

You can update to the 25.2.1 version from the following cluster versions:

  • Patch update: 25.2 (2025-09-23)

For the detailed cluster update schema, refer to MOSK cluster update schema.

Patch update impact and maintenance windows planning

The following table provides details on the impact of a MOSK cluster update to a patch release within the 25.2 series.

Note

For the detailed workflow of update to a patch release, refer to Update to a patch version.

Expected update impact

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 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 0

  • Non-distributed routers, non-HA mode - interruption up to 10 minutes 0

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

No impact
0(1,2)

You can bypass updating components of the cloud data plane to avoid the network downtime during Update to a patch version. By using this technique, you accept the risk that some security fixes may not be applied.

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 Cluster update.

Pre-update actions

Migrate KaaSCephCluster from a management to MOSK cluster

Since MOSK 25.2, the management cluster resources KaaSCephCluster and KaaSCephOperationRequest are deprecated and can be optionally migrated to the following Ceph resources of the corresponding MOSK cluster: MiraCeph, MiraCephHealth, MiraCephSecret, MiraCephMaintenance, and CephOsdRemoveRequest.

Mirantis recommends that you manually migrate KaaSCephCluster and KaaSCephOperationRequest resources from non-production management clusters to the corresponding MiraCeph resources of MOSK clusters to better prepare before automatic migration in one of the following releases. Although keep in mind that this migration is irreversible.

To manually test the migration on non-production clusters, set the following annotation in the metadata section of KaaSCephCluster on the management cluster:

apiVersion: kaas.mirantis.com/v1alpha1
kind: KaaSCephCluster
metadata:
  ...
  annotations:
    manual-get-rid-of-kaascephcluster: "true"

After setting this annotation, KaaSCephCluster will be automatically and safely removed from the management cluster and all Ceph management will be moved to the corresponding Ceph CRs of a MOSK cluster.

Prevent Docker restarts on manager nodes

Since MOSK 25.2 and MOSK management 2.30.0, MCR 25.0.12 is installed on manager nodes of MOSK and MOSK management clusters. This MCR version contains a compatibility issue with sending of telemetry statistics, which causes the Docker daemon, Docker container, and MKE-related services to restart every 24 hours.

As a temporary solution, disable sending of telemetry statistics in MKE as described in [7947] Docker panic causes its service restarts every 24 hours.