MOSK 26.1: Resilient Lifecycle Management, Stronger OpenStack Networking, and AI Assistant for Documentation

MOSK 26.1 strengthens three areas that matter most in production environments: lifecycle management, OpenStack networking, and access to operational knowledge. For infrastructure operators, that means better backup and upgrade workflows, more flexibility in how clouds are configured and managed over time, and faster access to guidance when working across a complex stack of components and services. For cloud users, it means stronger networking capabilities for demanding use cases, more predictable performance, and a platform they can rely on.

Stronger OpenStack networking, bare metal, and HA capabilities

MOSK 26.1 brings a major set of enhancements to OpenStack, with a strong focus on networking and infrastructure capabilities that matter in production environments. In this release, Mirantis continues to expand and harden Open Virtual Network (OVN) support, making key features broadly available and easier to adopt with confidence.

With release 26.1, features such as VPNaaS based on IPSec, quality of service for north-south traffic, and SR-IOV support are now tested and documented for OVN-based MOSK clouds. These capabilities help operators build clouds aligned with demanding enterprise and edge use cases. IPSec VPNaaS support allows cloud users to build secure connectivity between OpenStack clouds and their own premises, or between their projects in different MOSK clusters. SR-IOV is a common way to improve performance for latency-sensitive workloads by giving virtual machines direct access to network hardware. QoS for north-south traffic adds another layer of control, helping operators enforce predictable network behavior for external-facing workloads.

MOSK 26.1 also improves Bare Metal as a Service (OpenStack Ironic) with Redfish virtual media provisioning. This enhancement simplifies provisioning of modern servers and improves the cloud operator experience in environments where traditional PXE-based flows can be difficult or unreliable.

An update to Instance HA (OpenStack Masakari) now makes it possible to apply instance evacuation behavior selectively, helping cloud operators align failover policies with business priorities and available infrastructure capacity. Mirantis added project-aware logic to the Masakari evacuation flow so that when a compute host failure occurs, the recovery process no longer treats all tenant workloads the same way. Instead, it can evaluate metadata associated with the affected OpenStack project and use that information to decide whether instances from that project should be included in automated recovery.

In practice, this allows operators to mark selected projects as eligible for Instance HA while leaving others outside the automatic evacuation policy. This model is especially useful in clouds where failover capacity is limited and not every workload can be given the same recovery guarantees. Rather than reserving spare infrastructure for all tenants equally, operators can prioritize critical applications, premium service tiers, or business-sensitive environments.

Software delivery transparency with SBOM

MOSK introduces Software Bill of Materials (SBOM), giving customers a clearer view of the components included in each release. This aligns with a broader industry shift: SBOMs are increasingly expected as part of secure software delivery, especially in regulated environments and public-sector procurement.

Mirantis now publishes SBOMs for MOSK in CycloneDX format, covering key release artifacts such as container images, binaries, and Ubuntu packages. This matches common market practice, where organizations want machine-readable SBOMs they can feed into security, governance, and audit workflows. It is especially relevant for sectors with stricter compliance expectations, including government, telecom, and healthcare.

The published SBOMs are also cryptographically signed, helping customers verify that the software metadata matches what Mirantis shipped. For platform teams, this makes SBOM support not just a documentation feature, but a practical tool for vulnerability management, license compliance, and supply chain assurance.

Lifecycle management enhancements

A major enhancement in this release is an improved backup system for management clusters. MOSK 26.1 adds support for external backup storage, encryption, manual and scheduled backups, and automatic backup creation before cluster updates. Together, these improvements help reduce operational risk and give platform teams a stronger foundation for disaster recovery and upgrade readiness.

Upgrade visibility is also improved for environments using OpenSDN. During upgrade operations, OpenSDN can now report more detailed progress and state information through the NodeWorkloadLock API, giving operators better insight into what the subsystem is doing at each stage. This makes upgrade workflows easier to monitor and troubleshoot, especially in complex environments where clear status reporting matters.

A major milestone in MOSK is full Ubuntu 24.04 LTS support across the product, including the standard host OS configuration modules used to configure and fine-tune host OS settings on cluster nodes consistently. Ubuntu 24.04 brings a newer platform baseline, including the Linux 6.8 kernel, which improves support for newer server hardware and gives cloud operators access to current kernel, driver, and userspace capabilities. From a security perspective, Ubuntu 22.04 remains supported today, but its standard support window ends in April 2027, after which continued coverage depends on Extended Security Maintenance. That makes MOSK 26.1 an important transition release for customers planning hardware refreshes and long-term security patching strategies.

Another important step forward is more granular control over host OS configuration. MOSK 26.1 continues moving host-level settings into dedicated configuration modules, allowing operators to manage changes more precisely instead of relying only on cluster-wide settings. This gives teams a better way to roll out updates gradually, validate changes on selected nodes, and reduce the operational risk of broad configuration changes in large-scale environments.

Security controls for cloud access and control plane traffic

MOSK 26.1 adds the ability to place the Keycloak public endpoint on a dedicated network, giving operators more control over how central identity services are exposed. In MOSK, Keycloak is part of the central IAM system running on the management cluster and commonly serves as the authentication endpoint for both cloud operators working with lifecycle management APIs and cloud users accessing OpenStack APIs. Because the same identity service is shared across administrative and tenant-facing access paths, its network exposure has a direct impact on security boundaries. By allowing the Keycloak endpoint to be published through a dedicated network segment and MetalLB pool, MOSK 26.1 helps enforce stricter separation between operator and user traffic and reduce unnecessary exposure.

MOSK 26.1 also continues to support encryption of underlay Kubernetes traffic, helping secure control plane communication inside the cluster itself. This covers traffic exchanged between core platform components and services, adding protection for sensitive east-west communication within the infrastructure.

Simplified lifecycle management for storage

MOSK 26.1 continues to improve the storage architecture by advancing the transition to a more cluster-local lifecycle management model for Ceph. With this release, Pelagia, Mirantis’s open source Ceph controller project, operates fully on MOSK clusters, so Ceph is managed directly in the environment where it is deployed rather than through the management cluster.

This approach simplifies the operational model for storage by aligning lifecycle management more closely with the cluster that actually runs the storage services. It helps reduce cross-cluster dependencies, makes storage operations more self-contained, and creates a cleaner separation between central management functions and cluster-level data plane services. For operators, this means a more consistent and scalable way to manage containerized Ceph as part of the overall MOSK platform.

Release 26.1 also brings Ceph dashboards back into the MOSK Management Console, improving visibility into storage health and status from the central management interface. This gives operators a more convenient way to monitor Ceph environments while preserving the cluster-local lifecycle model underneath.

Improved visibility across infrastructure and platform operations

On the monitoring side, MOSK 26.1 adds support for software RAID monitoring, giving operators better insight into the health of storage devices on nodes that rely on software RAID configurations. The release also introduces node power metrics collected through IPMI, making it easier to track energy consumption and hardware-level power characteristics across the cluster. For environments running resource-intensive workloads such as AI/ML, this provides another useful data point for infrastructure planning and operational analysis.

The release also improves visibility into compute-node performance with more granular NUMA-node monitoring. This helps operators detect imbalances in memory consumption and resource usage across NUMA boundaries, which can be especially important for performance-sensitive workloads and larger compute configurations.

AI assistant for documentation and operational guidance

MOSK customers can now access an AI assistant for MOSK documentation through the Mirantis support portal. Built on kapa.ai, the assistant is designed to provide accurate answers from technical documentation and connected knowledge sources, with source-grounded responses rather than generic chatbot output.

MOSK is a complex platform spanning many layers, from the management cluster and lifecycle APIs to Kubernetes, OpenStack services, networking, storage, and observability. Operating it efficiently often requires knowing where in the stack a given feature, issue, or procedure belongs. An AI assistant helps shorten that path: instead of manually navigating across many documentation sections, cloud operators can ask task-oriented questions and get faster, more targeted guidance. That can reduce time spent searching for procedures, speed up troubleshooting and Day 2 operations, and make it easier for teams to work effectively even when deep technology expertise is concentrated in a smaller number of specialists.

Conclusion

Taken together, the improvements in MOSK 26.1 help cloud providers and enterprise platform teams operate OpenStack clouds more effectively, support a wider range of business and technical requirements, and improve the experience for end users. Enhanced lifecycle management helps reduce operational overhead and improve upgrade readiness, stronger OpenStack networking expands the range of cloud services that can be delivered with confidence, and the AI assistant for documentation makes it easier for operators to navigate a complex technology stack and resolve issues faster. MOSK 26.1 is a release designed to deliver practical value in day-to-day cloud operations.