New features

OpenStack Caracal LTS support

Implemented full support for OpenStack Caracal with Open vSwitch and Tungsten Fabric networking backends for greenfield deployments and for an upgrade from OpenStack Antelope. To upgrade an existing cloud from OpenStack Antelope to Caracal, follow the Upgrade OpenStack procedure.

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

Highlights from upstream OpenStack supported by MOSK deployed on Caracal

Horizon:

  • Horizon added TOTP authentication support, allowing users to enhance their security by authenticating with Time-based One-Time Passwords.

Manila:

  • Manila shares and access rules can now be locked against deletion. A generic resource locks framework has been introduced to facilitate this. Users can also hide sensitive fields of access rules with this feature.

Neutron:

  • Limit the rate at which instances can query the metadata service in order to protect the OpenStack deployment from DoS or misbehaved instances.

  • New API which allows to define a set of security group rules to be used automatically in every new default and/or custom security group created for any project.

Nova:

  • It is now possible to define different authorization policies for migration with and without a target host.

To view the full list of OpenStack Antelope features, including those not supported by MOSK, refer to OpenStack Caracal upstream documentation: Release notes and source code.

Tungsten Fabric Horizon plugin removal

Since the OpenStack Caracal release, the Tungsten Fabric Horizon plugin has been deprecated and removed. This change impacts the Networking panel in OpenStack Horizon, which previously allowed for managing Network IPAMs and Network policies. With the removal of this plugin, Horizon no longer supports these features.

As a result, cloud operators may encounter Tungsten Fabric service networks with snat-si in their names. These networks will be visible in the network tabs and during the creation of ports or instances. Mirantis advises cloud operators not to interact with these networks, as doing so may cause system malfunctions.

Ubuntu 22.04 LTS support

Implemented full support for Ubuntu 22.04 LTS (Jammy Jellyfish) as the default host operating system in MOSK clusters, including greenfield deployments and update from Ubuntu 20.04 to 22.04 on existing clusters.

Ubuntu 20.04 is unsupported for greenfield deployments and is considered deprecated during the MOSK 24.3 release cycle for existing clusters.

Note

Since Container Cloud 2.27.0 (Cluster release 16.2.0), existing MOSK management clusters were automatically updated to Ubuntu 22.04 during cluster upgrade. Greenfield deployments of management clusters are also based on Ubuntu 22.04.

Instance migration for non-administrative OpenStack users

Implemented the capability for non-administrative OpenStack users to migrate instances, including both live and cold migrations. This functionality is useful when performing different maintenance tasks including cloud updates, handling noisy neighbors, and other operational needs.

External OIDC identity providers for OpenStack

TechPreview

Implemented the capability to connect external OpenID Connect (OIDC) identity providers to MOSK Identity service (OpenStack Keystone) directly through the OpenStackDeployment custom resource.

Custom volume backend for Cinder

TechPreview

Introduced the ability to configure custom volume backends for MOSK Block Storage service (OpenStack Cinder), enhancing flexibility in storage management. Users can now define and deploy their own backend configurations through the OpenStackDeployment custom resource.

Graceful instance shutdown

Implemented the capability to automatically power off the guest instances during the compute node shutdown or reboot through the ACPI power event. This ensures the integrity of disk filesystems and prevents damage to running applications during cluster updates.

Shared Filesystems as a Service

Introduced general availability support for the MOSK Shared Filesystems service (OpenStack Manila), allowing cloud users to create and manage virtual file shares. This enables applications to store data using common network file-sharing protocols such as CIFS, NFS, and more.

Cluster self-diagnostics

TechPreview

Implemented the Diagnostic Controller that performs cluster self-diagnostics to help the operator to easily understand, troubleshoot, and resolve potential issues against the major cluster components, including OpenStack, Tungsten Fabric, Ceph, and StackLight.

Running self-diagnostics is essential to ensure the overall health and optimal performance of a cluster. Mirantis recommends running self-diagnostics before cluster update, node replacement, or any other significant changes in the cluster to prevent potential issues and optimize the maintenance window.

Etcd as a backend for TaskFlow

Implemented etcd as a backend for TaskFlow within Octavia, offering a scalable, consistent, and fault-tolerant solution for persisting and managing task states. This ensures that Octavia reliably handles distributed load balancing tasks in a Kubernetes cluster.

vRouter Provisioner moved to separate DaemonSet

Separated the vRouter provisioner from other Tungsten Fabric components. Now, the vRouter provisioner is deployed as a separate DaemonSet tf-vrouter-provisioner to allow for better control over the vRouter components.

Automatic conversion to Tungsten Fabric Operator API v2

Implemented the automatic conversion of the Tungsten Fabric cluster configuration API (TFOperator) v1alpha1 to the v2 version during update to MOSK 24.3.

Since MOSK 24.3, the v2 TFOperator custom resource should be used for any updates. The v1alpha1 TFOperator custom resource will remain in the cluster but will no longer be reconciled and will be automatically removed with the next cluster update.

Monitoring of Nova orphaned allocations

Implemented monitoring of orphaned allocations in the MOSK Compute service (OpenStack Nova). This feature simplifies the detection and troubleshooting of orphaned resource allocations, ensuring that resources are correctly assigned and utilized within the cloud infrastructure.

PowerDNS health monitoring

Implemented health monitoring of the PowerDNS backend for MOSK DNS service (OpenStack Designate) using StackLight that allows detecting and preventing PowerDNS issues. Started scraping a set of metrics to monitor PowerDNS networking and detect server errors, failures, and outages. Based on these metrics, added the dedicated OpenStack PowerDNS Grafana dashboard and several alerts to notify the operator of any detected issues.