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 enable, configure, and use them.

OpenStack

OpenStack Gazpacho

Implemented full support for OpenStack Gazpacho with Open vSwitch (OVS), OpenSDN, and Open Virtual Network (OVN) networking backends for both greenfield and existing MOSK deployments.

Learn more

OpenStack infrastructure components update

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

Component

26.2 (current)

26.1.2

26.1

etcd

3.6.14

3.5.33

3.5.26

FRR

10.6.1

9.1.2

9.1.2

NGINX

1.31.2

1.29.8

1.27.5

PowerDNS

5.0.3

4.9.4

4.9.4

RabbitMQ

4.3.2

4.0.6

4.0.6

Redis

8.6.3

7.4.6

7.4.6

strongSwan

5.9.14 (FIPS mode enabled)

5.9.14

5.9.14

Learn more

Release artifacts

Application Gateway replaces NGINX Ingress

Implemented Application Gateway, an Envoy Proxy instance managed by the Envoy Gateway controller, as the default ingress layer for OpenStack, Ceph, and OpenSDN public endpoints. Application Gateway provides full functional and operational parity with NGINX Ingress. NGINX Ingress remains available during a transition period and will be fully retired in a future release.

For existing clusters, migration to Application Gateway is manual and must be performed by following the documented procedure.

Learn more

Operations Guide: Migrate public endpoints to Envoy Proxy

New Tenant Telemetry stack

TechPreview

Reintroduced the Tenant Telemetry service on a new metrics stack that replaces Gnocchi. The service exposes OpenStack Ceilometer metrics to tenant users so that they can drive autoscaling decisions through OpenStack Heat, and is available starting with the OpenStack Gazpacho release.

The new metric-storage service introduces the following components:

  • Aetos, a Keystone-aware reverse proxy that enforces tenant separation in front of Prometheus and exposes a tenant-facing subset of the Prometheus API. Aetos is registered in the OpenStack service catalog as the metric-storage service type.

  • sg-core, which ingests the metrics that Ceilometer collects and re-exposes them for Prometheus to scrape. It runs as a sidecar container alongside each Ceilometer notification agent pod.

  • Prometheus, a dedicated instance used to store Tenant Telemetry data, kept separate from the StackLight instance.

Warning

Moving to the new Tenant Telemetry stack is a breaking change. Read carefully about data and user impact in the Migrate Tenant Telemetry from Gnocchi and plan the migration accordingly.

Learn more

OpenSDN

OpenSDN 25.1

Implemented support for OpenSDN 25.1 alongside OpenSDN 24.1 for MOSK clusters running OpenStack Gazpacho. Deploy OpenSDN 25.1 directly on greenfield clusters, or upgrade an existing OpenSDN 24.1 deployment using the Upgrade OpenSDN from 24.1 to 25.1 procedure.

This release brings a significant platform and architecture update:

  • Base operating system for OpenSDN nodes migrated to Rocky Linux 9, with full completion of the Python 3.9 migration across all components

  • BGP-as-a-Service (BGPaaS) routing moved from the vRouter Agent to the Controller

  • BGP Large Community attribute support added

  • vRouter dataplane now supports Linux kernel 6.x, is Linux-only, with legacy Linux 2.6 compatibility and FreeBSD/Darwin platform support removed

  • Web UI rebranded from Tungsten Fabric to OpenSDN, with a new toggle for making all tags global

  • Web UI container updated to a Node.js 24 runtime

  • Octavia/Amphora LBaaS hardened

Learn more

Operations Guide: Upgrade OpenSDN from 24.1 to 25.1

OpenSDN third-party components update

Updated the following third-party infrastructure components used internally by OpenSDN to newer supported versions, ensuring full functional compatibility with both OpenSDN 24.1 and OpenSDN 25.1:

Component

26.2 (current)

26.1.2

26.1

Cassandra

4.1.11

4.0.20

4.0.19

Redis

8.6.4

7.4.8

7.4.6

ZooKeeper

3.9.5

3.9.5

3.9.4

Learn more

Release artifacts

Node.js runtime update for OpenSDN Web UI

Updated the Node.js runtime of the OpenSDN Web UI container from the end-of-life Node.js 16 to a maintained LTS release, closing the critical and high CVEs that accumulated in the outdated runtime:

  • For OpenSDN 24.1, Node.js 16 updated to Node.js 22

  • For OpenSDN 25.1, Node.js 16 updated to Node.js 24

Learn more

Security and compliance

FIPS 140-3 validated cryptography for IPsec traffic encryption

strongSwan establishes and maintains the IPsec tunnels that keep tenant east-west traffic between compute nodes confidential in transit. In this release, strongSwan is rebuilt against a FIPS 140-3 validated OpenSSL module for Internet Key Exchange (IKE), the protocol that authenticates peers and negotiates tunnel keys. With FIPS mode enabled, userspace cryptography now matches the already FIPS-enabled kernel IPsec path.

Learn more

DISA STIG compliance for host operating systems

Introduced Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) support on host operating systems of MOSK and management clusters. DISA STIG is a set of cybersecurity standards defined by the U.S. Department of Defense (DoD).

MOSK applies non-impactful DISA STIG controls in the default host operating system configuration. For remaining controls that might affect operations and are therefore considered environment-specific, Mirantis provides host OS configuration recipes that cloud operators can apply to the cluster. This release also documents the validated STIG benchmark pass rate and remaining exceptions.

Learn more

Security Guide: DISA STIG

MOSK management

Kubernetes 1.33 for management clusters

Updated the Kubernetes version of management clusters from 1.30 to 1.33 in the scope of the migration from MKE to k0s. The update is performed automatically during the update to MOSK management 2.32.0.

Note

For MOSK clusters, the Kubernetes version remains the same as in the previous release.

Learn more

Kubernetes 1.33 Release Notes

k0s as the Kubernetes distribution for management clusters

Introduced k0s as the Kubernetes distribution of the management cluster underlay, replacing Mirantis Kubernetes Engine (MKE). k0s is a fully upstream, CNCF-certified Kubernetes distribution that ships as a single self-contained binary and runs the Kubernetes control plane components as host processes supervised by systemd, without the Docker Swarm layer.

An existing management cluster is migrated from MKE to k0s automatically during the update to MOSK management 2.32.0. The migration happens in place, the cluster keeps its etcd data, and no manual steps are required to start or drive it.

MOSK clusters are not affected by this change and keep running MKE. Their automatic transition to k0s is planned for a future release and will be announced separately.

The adoption of k0s brings the following changes to the management cluster operations:

  • The MKE web UI, the MKE API, including the MKE configuration in the TOML format, and the MKE client bundle are no longer available. Use the MOSK management console, Kubernetes API, and StackLight dashboards instead.

  • The MKE-specific Secure Overlay feature, which is based on IPsec, is replaced by Calico WireGuard encryption.

  • The Kubernetes underlay configuration became fully declarative. It is managed through the Cluster object, which now exposes the extraArgs of the Kubernetes API server, controller manager, scheduler, and etcd, a common kubelet configuration through workerProfile, and Kubernetes featureGates.

  • Any change of the Kubernetes underlay configuration restarts the Kubernetes control plane on the control plane nodes sequentially, with a cordon and drain of one node at a time.

Important

The migration is a one-way operation. A management cluster cannot be rolled back to MKE once the migration is initiated. Mirantis does not claim full feature parity between MKE and k0s. Review the limitations and the required pre-update and post-update actions before the update.

Learn more

MCR 25.0.17 for all clusters

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

Learn more

Mirantis Container Runtime 25.0.17 Release Notes

Per-node scope control in NodeMaintenanceRequest

Implemented the ability to create NodeMaintenanceRequest objects with different scopes within a single cluster maintenance. This enables granular scope control during operations with UpdateGroups that may require rebooting only specific node groups.

The scope field of the ClusterMaintenanceRequest resource was deprecated in MOSK 26.1 and removed in 26.2 in favor of the same field in the NodeMaintenanceRequest resource.

Learn more

Refined Clusters view in the MOSK management console

Refined the Clusters page of the MOSK management console to focus on the information that is essential for MOSK cloud operators:

  • Added the Type column indicating whether a cluster is a management or MOSK one.

  • Added the Nodes column displaying the number of OpenStack controller, compute, storage, and gateway nodes of a MOSK cluster.

  • Removed the Provider and Age columns as excessive. All MOSK deployments use the bare-metal provider, and the cluster creation date is still available through the Cluster info option of the More action menu.

Learn more

Operations Guide: Access the management console

Host operating system configuration status in the machine status

Introduced representation of HostOSConfiguration changes in the machine status, available both through the API and in the MOSK management console. This provides visibility into pending and applied host operating system configuration changes on a per-machine basis.

The machine status now reflects the following states:

  • A configuration change that is pending or running for a machine. A change can remain pending because the machine is not ready, for example, not yet fully deployed, or because the agent has not started the change yet.

  • A configuration change that has finished on a machine, with the propagated result and an error message in case of failure.

In the MOSK management console, the Host OS Configurations machine component indicates the overall status of changes being applied. If applying a change fails, the Warning tooltip next to the machine name provides a meaningful explanation. When a change requires a machine reboot to take effect, the machine status indicates this along with the configuration change that requires the reboot.

Learn more

Operations Guide: Verify machine status

Immutable Mirantis Container Runtime repository snapshots

Introduced immutable (pinned) snapshots of the Mirantis Container Runtime (MCR) repository, consumed through a new mcr_ubuntu_repo parameter in ClusterRelease that points cluster nodes to a stable MCR snapshot instead of the live repos.mirantis.com repository.

The feature eliminates the need for custom snapshots: the required snapshot is selected by ClusterRelease and synced automatically. This keeps package sources reproducible across re-syncs and updates. It also allows air-gapped deployments to reliably validate cached content and prevent synchronization failures.

Learn more

Support dump collection

TechPreview

Introduced supportdump-controller, which collects logs and Kubernetes objects from a management or MOSK cluster into a single archive. Instead of gathering data through the bootstrap CLI, SSH keys, and node access, you can now create a SupportDump custom resource that describes what to collect, and attach the resulting archive to a support case. This reduces follow-up requests for missing logs and configuration.

The controller runs on the management cluster and watches for SupportDump objects. It is installed automatically with the management cluster update.

The collection also works for MOSK clusters of earlier releases. In the Technology Preview scope, support dumps can be collected by management cluster administrators only.

On management clusters running a version earlier than MOSK management 2.32.0, the controller can be installed manually as described in the documentation for that release. For example, Install the support dump controller.

Learn more

Logging, monitoring, and alerting

Major version update of OpenSearch and OpenSearch Dashboards

Updated OpenSearch and OpenSearch Dashboards from major version 2.19.4 to 3.5.0. The latest version includes significant performance improvements for search queries along with bug and security fixes.

Learn more

Monitoring of k0s-based clusters

Implemented monitoring of k0s-based clusters. Alongside the existing MKE-based support, StackLight now monitors the k0s control plane and collects k0s logs. Monitoring of the k0s Pushgateway includes the following alerts:

  • k0sPushgatewayTargetDown

  • k0sEtcdMemberDown

Note

During the management cluster update, several StackLight alerts may fire as an expected, temporary effect of the migration from MKE to k0s. For details, see StackLight alerts firing during the management cluster update.

Learn more

Operations Guide: StackLight alerts - k0s

Monitoring of the mcc-cache service availability

Implemented monitoring of the mcc-cache service availability by emulating Docker image and Helm chart pulls through the Prometheus Blackbox Exporter. Management clusters are monitored directly through the mcc-cache Kubernetes service and its pods, while MOSK clusters are monitored per node through a local NGINX proxy.

The feature is enabled by default using the mccCacheMonitoring.enabled StackLight parameter and includes the following alerts:

  • MCCCacheClusterProbeFailed

  • MCCCacheNodeProbeFailed

  • MCCCachePodProbeFailed

  • MCCCacheServiceProbeFailed

In the scope of this implementation, the http_mcc_cache Blackbox Exporter module was added along with the mcc-cache-docker-registry and mcc-cache-helm-repo scrape jobs that perform the probes.

Learn more

Alerts about zombie processes

Implemented the StackLight ZombieProcessesDetected alert to detect zombie processes that can accumulate on MOSK nodes and cause process ID exhaustion as well as potentially mask deeper issues such as stuck container runtimes or kernel bugs. This alert allows you to identify and mitigate these issues before they affect system stability.

Learn more

Native Alertmanager integration with Microsoft Teams

Switched from the deprecated prometheus-msteams service to using the Alertmanager native msteamsv2_config receiver for sending Alertmanager notifications to Microsoft Teams. You can now configure it through the generic alertmanagerSimpleConfig.genericReceivers and genericRoutes parameters.

Learn more

Switch from Prometheus Relay to Promxy

Switched from the Prometheus Relay service to Promxy as the high-availability query layer in front of the two Prometheus instances. Promxy merges and deduplicates query results across the instances so queries return a single, complete answer even when data is skewed or missing on one of them.

The Grafana Prometheus datasource now points to Promxy. Optionally, you can also route external Prometheus access through Promxy using the new iam.proxyPrometheusUpstream parameter, which is set to prometheus-server by default. To configure the query timeout, use the promxy.queryTimeout parameter.

Prometheus Relay is now deprecated.

Learn more

Monitoring of Envoy Gateway

Reworked StackLight monitoring of the OpenStack public API to align with the transition from the OpenStack Ingress Controller to Envoy Gateway. In the scope of this change, StackLight introduces the following components:

  • The Envoy Gateway Grafana dashboard that monitors the number of requests, response times and statuses per HTTPRoute, active downstream connections, successful and failed Envoy configuration reloads, as well as the number of Envoy SSL certificates including expiration time and per-route bandwidth.

  • The EnvoyProxyTargetsOutage alert that raises when Prometheus fails to scrape metrics from all Envoy proxy endpoints.

  • The OpenstackEnvoyPublicAPI401Warning and OpenstackEnvoyPublicAPI5xxCritical alerts that report per HTTPRoute.

  • The envoy-proxy scrape job with a set of metrics to monitor Envoy proxy.

Learn more

Public API probes for Object Storage

Expanded public API probes to cover the Object Storage (Ceph RGW) public API. The probes check endpoint availability, response times, and SSL certificate expiration on HTTPRoute objects auto-discovered in the rook-ceph namespace. They run every 30 seconds with a 15-second timeout as the public-api-probes scrape job.

This change is part of the transition from the OpenStack Ingress Controller to Envoy Gateway, in the scope of which StackLight also switched the existing OpenStack public API probes from the OpenStack Ingress Controller to Envoy Gateway. As a result, both the OpenStack and Object Storage public APIs are now monitored by the same set of alerts:

  • PublicApiCertExpirationHigh

  • PublicApiCertExpirationMedium

  • PublicApiProbeFailing

  • PublicApiTargetsOutage

These alerts replace the deprecated OpenstackSSLCertExpiration* and OpenstackSSLProbes* alerts.

Learn more

Monitoring of SNAT source port usage

Added monitoring of SNAT source port consumption inside Neutron router namespaces on OpenStack gateway nodes. Operators can now track and alert on rapid growth in connections to a single destination, catching potential SNAT source-port exhaustion before it degrades tenant traffic.

Monitoring is performed by a new prometheus-neutron-snat-exporter DaemonSet that reads connection tracking data directly through the ctnetlink kernel API, requiring no conntrack or nsenter binaries. It is enabled by default on MOSK clusters using the OVS Neutron backend and ranks destinations by connection count, ensuring that those nearing port exhaustion are always captured regardless of cardinality limits.

Learn more

Ceph

Ceph Tentacle

Upgraded Ceph from Squid 19.2 to Tentacle 20.2 with an automatic upgrade of Ceph components on existing MOSK clusters during cluster update.

Ceph Tentacle also delivers new image versions for the following components:

  • rook - 1.19

  • cephcsi - 3.16

  • csi-provisioner - 6.1

For Rook, the main change in the Ceph Filesystem CRD is the behavior of the activeStandby property. When set to false, the standby MDS daemon deployment is now removed entirely, instead of only disabling its cache while keeping the daemon running.

Learn more

CephDeployment API refactoring

Refactored the CephDeployment API to use native Rook API structures for fields that were previously duplicated. This simplifies implementation of new Rook features and reduces the complexity of the CephDeployment API. Migration of existing CephDeployment objects to the new API occurs automatically during cluster update, so no manual steps are required.

The following fields are deprecated and will be migrated automatically to new locations during cluster update:

  • dashboard

  • external

  • healthCheck

  • ingressConfig

  • mgr

  • network

  • objectStorage.multisite

  • objectStorage.rgw

  • pools

  • sharedFilesystems.cephFS

Caution

Mirantis highly recommends using new locations for the deprecated fields. Using both the old and new locations simultaneously causes a reconciliation failure.

Learn more

API Reference: CephDeployment custom resource

Support for multiple ObjectStore (Ceph RGW) instances

Refactoring of the CephDeployment API enables support for multiple ObjectStore (Ceph RGW) instances. With this feature, a single Ceph cluster can serve multiple independent ObjectStore instances, allowing you to isolate object storage per workload or tenant rather than sharing one RGW instance.

The following changes are introduced:

  • The RGW name of the StorageClass created by default for RGW has changed to <object-store-name>-bucket.

    The previously created StorageClass for a single ObjectStore (RGW) instance named rgw-storage-class is still present for backward compatibility. Existing buckets are not affected, but for newly created ones, use StorageClass with the new name. Optionally, you can manually remove the existing StorageClass with the old name if no ObjectBucketClaims exist with a reference to the old storage class.

  • The self-signed ObjectStore (RGW) SSL certificate is regenerated and renamed from rgw-ssl-certificate to <object-store-name>-ssl-certificate.

    If the current ObjectStore specification provides certificates in the SSLCert section, such certificates are placed under the common secret rgw-ssl-certificate in the rook-ceph namespace and will continue to be used. If the SSLCertInRef field is used, the same secret will be used. The secret names for both sections will be moved to the new corresponding sections of the ObjectStore specification.

    The SSLCert and SSLCertInRef sections will be removed. Specifying plain SSL certificates directly in the CephDeployment spec is now prohibited, so use a secret reference instead. For details, see Rook documentation: Enable TLS.

  • For security reasons, the multisite realm cannot provide plain realm keys in the spec anymore. You must create the corresponding secret as described in Rook documentation: Getting Realm Access Key and Secret Key. For existing environments, no actions are required.

  • Serving RGW DNS names must now be set using the ObjectStore (RGW) spec definition. This enables a more flexible configuration. For details, see Rook documentation: Hosting Settings. Existing environments do not require pre-upgrade steps, but consider switching to the new flow after upgrade.

Learn more

Rook documentation: Object Multi-instance

Gateway API support for Ceph Object Storage public endpoint

Introduced support for the Kubernetes Gateway API as the new default and supported way of exposing the Ceph Object Storage (RADOS Gateway) public endpoint through Application Gateway (app-gateway). This change is part of the transition away from NGINX Ingress, which is now deprecated upstream and scheduled for retirement.

Note

This feature covers only the Ceph integration with Application Gateway. The broader adoption of the NGINX Ingress replacement across MOSK is documented separately.

The Ceph controller (Pelagia) now exposes the RGW public endpoint through Application Gateway using the Gateway API. Use the new objectStorage.gatewayHTTPRoutes section of the CephDeployment custom resource to define the HTTPRoute specification for public access to Object Storage, including TLS termination through the Gateway controller.

Compatibility with the existing Ceph RGW daemon is preserved. The Gateway API path replaces only the way the public endpoint is exposed, so no changes to the RGW daemon configuration are required.

The NGINX Ingress-based configuration is deprecated in favor of Application Gateway. For details, see Deprecation Notes.

Learn more

Standalone Ceph CSI Operator for managing CSI resources

Extracted the Ceph CSI Operator from the Rook controller into a separate component that manages lifecycle of Ceph CSI driver resources independently. This change is part of the Rook version upgrade to 1.19. It allows for more flexibility in managing Ceph CSI driver resources and reduces the complexity of the Rook controller.

During upgrade, Rook automatically converts existing Rook CSI settings to the new CSI Operator settings. Ceph CSI Operator is enabled by default.

Learn more

Ceph CSI Operator README

Usage of monitorIP when deploying Ceph or Manila with CephFS

Added the monitorIP field of the nodes parameter of the CephDeployment CR to the default testing configuration and approved it as highly recommended for production deployments. Setting monitorIP to an IP address from the Ceph publicNet range enables Ceph Monitor daemons to run on the Ceph public network instead of the default LCM network. For staging environments, the field remains optional.

This is particularly relevant for deployments using the CephFS driver for the Shared Filesystems service (OpenStack Manila): by default, Ceph Monitor services are only accessible on the LCM network, requiring both the manila-share service and client VMs to have routing to that network. Configuring monitorIP removes this constraint for new deployments.

For existing deployments, the migration procedure to adopt monitorIP for Ceph Monitor services will become available in a future release.

Learn more

Visualizing Ceph clusters in the MOSK management console

Restored the Ceph cluster dashboard in the MOSK management console. The dashboard now works directly with the MOSK cluster-side LCM API and reads the CephDeployment and CephDeploymentHealth objects.

The dashboard became unavailable after the deprecation of the KaaSCephCluster API on management clusters, when Ceph life cycle management moved to the MOSK cluster side. With the transition to CephDeployment, the dashboard is back and operates in read-only mode.

To open the Ceph cluster detail view, click the Ceph Cluster link in the cluster information panel on the Clusters > <cluster-name> page. The view displays the overall Ceph cluster state, including the Ceph version, OSD statuses, health, maintenance and operational statuses, along with the list of Ceph nodes and their roles. The full CephDeployment specification is available through the Info kebab menu.

Note

The Ceph cluster dashboard is read-only. Creating, editing, and deleting Ceph objects is not available in the management console and can be performed using the CLI.

Learn more

Documentation

Smart switch between documentation versions

Updated the documentation version selector to retain your current section location when switching between MOSK documentation versions. If the section does not exist in the selected version, the portal redirects to the home page of the selected version.

Blueprint: NVIDIA ASAP² Direct datapath offloading

Published a new blueprint that documents the findings from enabling NVIDIA ASAP² Direct datapath offloading on MOSK compute nodes that use the Open vSwitch (OVS) kernel datapath.

The blueprint covers the validated architecture, network topologies, hardware and software requirements, host and OpenStackDeployment configuration, known limitations, and performance results compared with kernel OVS. The blueprint documents the results of Mirantis validation on specific hardware and firmware.

Learn more

Reference Architecture: Blueprints - NVIDIA ASAP² Direct datapath offloading

Blueprint: Short-lived token-based SSH access to cluster nodes

Published a new reference architecture blueprint that describes how to replace static, long-lived SSH keys with ephemeral, time-bound SSH certificates for access to MOSK cluster nodes.

The blueprint integrates HashiCorp Vault as an SSH certificate authority (CA) with Keycloak acting as the OpenID Connect (OIDC) provider:

  • Keycloak authenticates the operator, enforces multi-factor authentication, and issues OIDC tokens with user claims and group memberships.

  • Vault validates the OIDC token, maps Keycloak groups to Vault policies, and signs the operator ephemeral SSH public key with a strict time-to-live (TTL) and a limited set of allowed principals.

  • Cluster nodes trust the Vault SSH CA public key through the OpenSSH TrustedUserCAKeys option and validate incoming certificates locally, without querying Vault during login.

As a result, cloud operators obtain SSH credentials in a controlled, auditable, and user-friendly way, with no per-node user key management and with access that expires automatically.

Learn more

Reference Architecture: Blueprints - Short-lived token-based SSH access to MOSK cluster nodes

Exporting logs from OpenSearch using elasticdump

Added documentation on how to export more than 10 000 log entries from OpenSearch using the OpenSearch API and elasticdump, bypassing the log entry limit of the OpenSearch Dashboards CSV export.

Learn more

Operations Guide: StackLight operations - Export logs from OpenSearch using elasticdump

OpenSDN external BGP MPLS L3 VPN (VPNv4) export behavior

Added documentation clarifying that an external BGP peer receiving a large MPLS L3 VPN (VPNv4) routing table from OpenSDN control or network nodes is expected control-plane behavior, not evidence that the border router can forward into every tenant virtual network. The documentation explains the difference between control-plane visibility and forwarding and provides guidance on planning border-gateway integration.

Learn more

Host operating system disk layout

Added documentation that consolidates the host operating system disk layout for MOSK nodes by role. The documentation describes the common layout components, such as the system disk, Local Volume Provisioner, unpartitioned disks for Ceph OSDs, and partitions for compute and other OpenStack services. It also provides the recommended disks and partitions for each node role, including the management cluster, Kubernetes manager, OpenStack control plane, compute, storage, and hyperconverged nodes, as well as a disk size cheat sheet.

Learn more

Reference Architecture: Requirements - Host operating system disk layout