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 MCC). This means everything you need is in one place. The separate MCC documentation site will be retired, so please update your bookmarks for continued easy access to the latest content.

New features

This section highlights the newly introduced and enhanced capabilities in this release. Each feature includes a brief description and links to related documentation where applicable, so you can quickly explore how to configure and use them.

Major components version update

OpenStack Epoxy

Implemented full support for OpenStack Epoxy with Open vSwitch (OVS), Tungsten Fabric/OpenSDN, and Open Virtual Network (OVN) networking backends for greenfield deployments and for an upgrade from OpenStack Caracal. To upgrade an existing cloud to Epoxy, follow the Upgrade OpenStack procedure.

For the OpenStack support cycle in MOSK, refer to OpenStack support cycle.

To view the full list of OpenStack Epoxy features from upstream, refer to OpenStack Epoxy upstream documentation: Release notes and source code.

OpenSDN 24.1

Introduced support for OpenSDN 24.1, successor to Tungsten Fabric, enabling compatibility with latest features, APIs, and enhancements provided by the platform. You can now deploy, configure, and operate your MOSK environment with OpenSDN 24.1 to take advantage of its performance improvements and extended capabilities.

MOSK automatically upgrades Tungsten Fabric 21.4 to OpenSDN 24.1 during the cluster update from the MOSK 25.1 series to the 25.2 release. No extra maintenance window required.

Learn more

Ubuntu 24.04 for management clusters

Implemented automatic in-place upgrade of an operating system distribution from Ubuntu 22.04 LTS with kernel 5.15.0-143-generic to 24.04 with kernel 6.8.0-79-generic on management clusters. The distribution upgrade occurs as part of management cluster update that requires reboot of machines.

The feature support for MOSK clusters will be announced separately in one of the following releases.

Learn more

MKE with Kubernetes 1.30

Switched to a custom version of Mirantis Kubernetes Engine (MKE) with Kubernetes 1.30 and Calico 3.29.3 for both management and MOSK clusters. This MKE release is available exclusively for MOSK. For further details, contact Mirantis support.

MCR 25.0.12

Introduced support for Mirantis Container Runtime (MCR) 25.0.12. On existing MOSK clusters, MCR is automatically updated to this version during cluster update.

Learn more

MCR documentation: Release Notes

Ceph Squid

Upgraded Ceph major version from Reef 18.2 to Squid 19.2 with an automatic upgrade of Ceph components on existing MOSK clusters during the Cluster release update.

Ceph Squid also delivers new versions of the following components:

  • Rook - 1.17

  • cephcsi - 3.14

  • csi-provisioner - 5.2.0

Learn more

Keycloak 26.2.5

Upgraded the Keycloak major version from 25.0.6 to 26.2.5. For the list of new features and enhancements, see Keycloak Release Notes.

The upgrade path is fully automated. No data migration or custom LCM changes are required.

Learn more

OpenStack infrastructure components update

Updated the following OpenStack infrastructure components to their latest stable versions:

  • Major update:

    • MariaDB 11.4.5/26.4.21

    • RabbitMQ 4.0.6

    • Open vSwitch (OVS) 3.3

    • Open Virtual Network (OVN) 24.03.2

  • Minor update:

    • PowerDNS 4.9

    • Redis 7.4.2

    • Descheduler 0.32.2

    • Ingress-controller 1.12.1

  • Patch update:

    • Memcached 1.6.38

    • NGINX 1.27.4

    • Strongswan 5.9.14

Learn more

Release artifacts

Alertmanager API v2

Upgraded Alertmanager to version 0.28.1 that supports Alertmanager API v2. To unblock Alertmanager upgrade to this version, removed the deprecated Alertmanager API v1 that is not supported by Alertmanager 0.28.1.

If you rely on the Alertmanager API, ensure that all integrations and configurations are updated to use API v2, which is now the only supported version. Ongoing use of API v1 endpoints will result in errors or broken functionality after this upgrade.

OpenStack

Automated rotation of Octavia Amphora (LBaaS) certificates

Implemented an automated procedure for rotating TLS certificates of Octavia Amphora load balancers, ensuring certificates are renewed without manual reconfiguration. This reduces operational effort, minimizes downtime, and improves certificate management reliability. Operators can trigger the rotation using the osctl utility.

Learn more

Migration to Open Virtual Network

Expanded support for Open Virtual Network (OVN) as a networking backend for OpenStack to include not only MOSK greenfield deployments but also existing clusters using Open vSwitch (OVS) for networking. The migration tooling and procedure enable in-place migration from OVS with minimal downtime for user workloads.

Learn more

Remote serial console for bare metal nodes TechPreview

Introduced the capability to access bare metal nodes through the remote serial console. Login is available from both the web UI and CLI, allowing for simplified operations and reduced manual overhead compared to previous bare metal procedures.

Learn more

User Guide: Access the bare metal node console

Port trunking for Ironic TechPreview

Implemented support for the port trunking capability for Ironic instances through the networking-generic-switch Neutron driver allowing for a single NIC/port on a bare metal server to carry traffic for multiple VLANs simultaneously.

Learn more

Reference Architecture: Port trunking

Tungsten Fabric (OpenSDN)

Remote S3 storage for Tungsten Fabric backups TechPreview

Implemented the capability to configure synchronization of the Tungsten Fabric database backups with a remote S3 storage. This feature keeps backups off the control plane nodes for easier disaster recovery and improved data durability, and ensures that the backup data is protected by encryption both in flight and at rest.

Learn more

Reference Architecture: Remote S3 storage for Tungsten Fabric database backups

Removal of Tungsten Fabric analytics

Removed Tungsten Fabric analytics that has been unsupported since MOSK 24.2. On existing clusters, all Tungsten Fabric analytics services are automatically removed and the spec.services.analytics section is reset in the TFOperator custom resource during MOSK cluster update to 25.2.

Learn more

Deprecation Notes: Tungsten Fabric analytics services

MOSK management

Graceful node shutdown by default

Added the default graceful_shutdown kubelet profile to all node types. This profile sets --shutdown-grace-period and --shutdown-grace-period-critical-pods kubelet flags to 5 minutes and 30 seconds respectively before a planned or unexpected node shutdown. This feature allows the system to properly prepare itself for maintenance.

On existing clusters, these flags are automatically set after MOSK cluster update to MOSK 25.2.

The corresponding functionality already exists in Kubernetes and MKE. Also, you can gracefully shut down instances running on compute nodes during maintenance reboots.

Learn more

ClusterUpdatePlan as the primary API for cluster update

Introduced general availability support for ClusterUpdatePlan as the only supported way to update MOSK clusters. This method allows controlling cluster update by manually launching each update stage. Between update stages, a cluster remains functional from the perspective of cloud users and workloads. The feature is available using the management console and API.

Updating a cluster using the cluster.spec.providerSpec.value.release field is now rejected by admission-controller.

Learn more

Ceph

MiraCeph instead of KaaSCephCluster for Ceph management

Deprecated the KaaSCephCluster resource of management clusters and moved it to the following Ceph cluster management resources of MOSK clusters: MiraCeph, MiraCephHealth, MiraCephSecret, and MiraCephMaintenance. Also deprecated the management KaaSCephOperationRequest CR and replaced it by CephOsdRemoveRequest of a MOSK cluster.

In MOSK 25.2, migration of custom resources from management to MOSK clusters is optional. Although, to prepare for future migration, you can manually test it as described in Migrate KaaSCephCluster from a management to MOSK cluster.

Since MOSK 26.1, this migration will occur automatically. On existing clusters, after Ceph resources migration, any interaction with the Ceph cluster will be processed inside MiraCeph, MiraCephHealth, and MiraCephSecret resources. For comparison between a management cluster Ceph resource and a MOSK cluster Ceph resources, see Comparison of KaaSCephCluster and MiraCeph-related specifications.

Learn more

Ceph device filters

Introduced support for deviceFilter and devicePathFilter that allow specifying regexp by a name or path of a device to use for Ceph OSD deployment.

You can add these parameters as deviceLabels for nodeGroups where you can define N templates of regexp for the whole cluster with device names or device by-id that you can use in each nodeGroup.

Learn more

Increasing severity level for CephOSDSlow*Network alerts

Increased the severity level from warning to critical for CephOSDSlowClusterNetwork and CephOSDSlowPublicNetwork StackLight alerts as both can signalize that performance of VM volumes is affected.

Also, updated MOSK Troubleshooting Guide with troubleshooting steps for the networking issues that these alerts signal about.

Learn more

Logging, monitoring, and alerting

Alert for devices mounted as read-only on /var/lib/nova

Added the NovaDataDirectoryMountedRO alert that is triggered when a device is mounted on the /var/lib/nova directory in read-only mode instead of read-write one. Such behaviour may indicate potential disk failures. The alert enables operators to promptly investigate disk health and start evacuating workloads before the affected device fails completely.

Learn more

Operations Guide: StackLight alerts - Nova

Alerts for node uptime based on AMD erratum 1474

Implemented the SystemUptimeCritical and SystemUptimeWarning alerts to monitor uptime of Kubernetes nodes and prevent unexpected node restarts due to the known issue AMD erratum 1474 in AMD EPYC™ CPUs of the second generation that may stop responding after 1044 days.

Also, in the scope of this implementation, the cpu.info Node Exporter collector was enabled by default and the node_cpu_info metric was added to the prometheus-node-exporter scrape job.

Learn more

Alert for the Dashboard service unavailability

Added a new critical alert HorizonLoginFailure. The alert triggers when the MOSK Dashboard (OpenStack Horizon) becomes unavailable to cloud users, as determined by the inability of a test user to log in.

Learn more

Operations Guide: StackLight alerts - Horizon

Keycloak monitoring

Introduced Keycloak monitoring that allows the operator to monitor internally available Keycloak endpoints, the status of statefulSets and pods, along with the status of 4xx and 5xx HTTP responses. The implementation includes the dedicated set of alerts, the Keycloak Grafana dashboard, as well as the keycloak_user_events_total and http_server_requests_seconds_count metrics that are collected by the keycloak scrape job.

Learn more

Node Exporter configuration hardening

Reworked the Node Exporter configuration to optimize operational user experience by providing the following changes:

  • Added the following nodeExporter parameters to enable configuration of extra collectors:

    • extraArgs

    • extraVolumes

    • extraVolumeMounts

  • Added the NodeExporterCollectorFailure alert that is based on the node_scrape_collector_success metric

  • Removed conntrack from the list of collectors enabled by default, which collects only a subset of supported metrics and fails due to unsupported ones

  • Added the bondInterfaceMonitoring parameter to enable the possibility to disable monitoring of bond interfaces

Learn more

RabbitMQ monitoring rework

As the final part of the RabbitMQ monitoring rework, implemented the following changes:

  • Removed the deprecated prometheus-rabbitmq-exporter scrape job. Instead, use the rabbitmq-prometheus-plugin job, which is based on the native RabbitMQ Prometheus plugin ensuring reliable and direct metric collection.

  • Removed the deprecated RabbitMQ [Deprecated] Grafana dashboard. Instead, use the RabbitMQ Overview and RabbitMQ Erlang dashboards.

  • Removed the deprecated RabbitMQDown and RabbitMQExporterTargetDown alerts.

Warning

If you use deprecated RabbitMQ metrics in customizations such as alerts and dashboards, switch to the new metrics and dashboards before updating to MOSK 25.2 to prevent issues once the deprecated metrics and dashboard will be removed.

Learn more

Alerts for the openstack-cinder-volume service

Implemented alerts for the openstack-cinder-volume service to monitor its health and signal the user when the service is disabled, when more than 50% of volume services with same backend are down, or when at least one volume is down.

Learn more

Operations Guide: StackLight alerts - Cinder

Support for the Telegraf S.M.A.R.T configuration

Added support for configuring the Telegraf S.M.A.R.T input plugin that allows collecting S.M.A.R.T data for storage devices. Also, added the nodeSelector support for telegraf-ds-smart.

Learn more

Bare metal

Network infrastructure monitoring

Introduced the capability to monitor network connectivity between management or MOSK cluster nodes using ping checks. Monitoring the cluster underlay networking allows the operator to:

  • Reduce the time spent to diagnose outages and restore services

  • Correlate major software stack issues with the underlying infrastructure outages and visualize this data

  • Identify the weakest points in the software stack and improve product resilience

Caution

ICMP protocol for ping checks must be allowed within the whole network infrastructure including all baremetal hosts, switches, and routers in-between racks, if any.

On the StackLight side, the following features are available:

  • CnncAgentDown and CnncNodeDown alerts with corresponding alert dependencies

  • Infra - Cross Node Connectivity Grafana dashboard

Learn more

Migration of cluster:spec:loadBalancerHost to a load-balancer subnet

Refactored management of IPAM objects for configuring address allocation for cluster API endpoints by moving the cluster:spec:loadBalancerHost field logic into the load-balancer Subnet resource with the ipam/SVC-LBhost label. This subnet is now mandatory during creation of subnets for a new cluster.

On existing clusters, the cluster:spec:loadBalancerHost field is automatically migrated during cluster update to a newly created Subnet object with the ipam/SVC-LBhost label.

Learn more

Controlled machine provisioning and deployment

Improved the mechanism of bare metal machines provisioning and deployment by introducing additional stages for management and MOSK cluster deployment as well as for adding a new machine to an existing cluster.

The feature allows for a manual approval of machine provisioning and deployment stages, which drastically decreases the time spent on adjusting configuration of bare metal hosts and machines to fit hardware settings.

Learn more

Full L3 networking topology in management clusters TechPreview

Added support for full L3 networking topology in management clusters. The feature enables deployment of management cluster nodes in dedicated racks without the need for L2 layer extension between them.

Learn more

Security

CIS-Ubuntu compliance

Analyzed and reached 87% of pass rate in the CIS Benchmark compliance checks executed by the Nessus scanner for Ubuntu Linux 22.04 LTS Server L1 v2.0.0, revision 1.10. Moving forward, results of the latest CIS Benchmark validation will be published as required in the CIS-Ubuntu compliance in MOSK section of the Security Guide.

Caution

For clusters that are based on Ubuntu 24.04, the validation is ongoing and the results will be published in one of the following releases.

Learn more

Blueprints

Air-gapped cluster with a local mirror TechPreview

Implemented support for deployment of air-gapped clusters that are useful in financial and other security-concerned areas. Such clusters exist in isolated environments that have no Internet connection, neither direct nor proxied. Such an isolated environment provides all required network services, such as NTP, DNS, file resources, image registries, and so on. If required, you can also migrate an existing non-airgapped cluster to an air-gapped one.

Learn more

Blueprints: Air-gapped clusters

Documentation

Mirantis Container Cloud documentation becomes part of MOSK documentation

Finalized integration of the Mirantis Container Cloud (MCC) documentation into the Mirantis OpenStack for Kubernetes (MOSK) documentation set. Now, the MOSK documentation covers all product layers, including MOSK management (formerly MCC). This means everything you need is in one place.

The separate MCC documentation site will be retired soon, so please update your bookmarks for continued easy access to the latest content.

OpenStackDeployment spec:services documentation

Added documentation explaining how to use the spec:services section of the OpenStackDeployment custom resource.

Warning

Modifying spec:services may result in the OpenStack deployment becoming unstable or entering an inconsistent state. This capability is intended solely for operators with expert-level knowledge of configuration parameters and their implications, and only in cases the spec:features section does not offer the required level of control. Mirantis assumes no responsibility for any issues arising from the use of the spec:services mechanism.

Learn more