For optimal reading, please switch to desktop mode.
Welcome back to the StackHPC newsletter. Its been a busy few months and we have lots to share in this edition -
outcomes from our annual design summit, plans for new Rocky Linux and OpenStack releases, and our upcoming training
workshops to help you become an expert cloud admin.
– The StackHPC team
StackHPC Design Summit 2026
At the start of June, StackHPC’s international colleagues travelled to our home in Bristol for a week to review 2026 so far,
and to plan for the imminent rollout of OpenStack Gazpacho and Rocky Linux 10. Alongside this, a restructure of our platforms team,
and a healthy dose of Somerset’s finest cider in the evenings.
We took this week as an opportunity to finally celebrate StackHPC’s 10th birthday with the whole team in-person, and welcome several
new faces as our platforms and infrastructure teams continue to grow.
Become an expert in cloud operations
Upcoming workshops in September and October are now sold out, please contact info@stackhpc.com to enquire about future sessions.
A core goal of our work at StackHPC is to give customers the ability to be self-sufficient. Developing the skills to manage day-to-day running of the cloud gives operators the power to
resolve common problems, customise their cloud and better support their users.
To this end, we frequently provide training to customer teams on their newly deployed systems to familiarise them with their environment, as well as mixed group training sessions that individuals.
We assume very little prior knowledge of OpenStack. So the training is accessible to a range of levels, whether you are new to cloud operations, or looking to refresh your knowledge
and dive into more advanced topics in the later sessions.
- The workshop starts with an introduction to OpenStack and its component projects,
- as well as Kolla and Kayobe (the StackHPC developed methods for deploying
containerised OpenStack).
- Participants are given access to their own virtualised bare metal lab instance which
- is set up to give the experience of deploying an OpenStack cloud using Kayobe’s
command line interface.
- This basic initial deployment will be built upon during the subsequent sessions,
- by the end of which, attendees will be experienced in making a variety of config
changes to their clouds.
- Other topics covered include deploying our standard monitoring and logging stack,
- managing storage with Ceph, and an introduction to OVN networking.
The View from the Release Train - Infrastructure updates and roadmap
Rocky Linux 10 (RL10) and OpenStack 2026.1 “Gazpacho”
The upstream OpenStack community released Gazpacho (2026.1) in April this year, and our infrastructure team is close to completing StackHPC Kayobe Config 2026.1,
a containerised implementation of our downstream OpenStack.
For systems based on a Rocky Linux host operating system, Gazpacho will be the first OpenStack release to mandate Rocky 10. The current release, Epoxy, runs on both RL9 and RL10 to allow for migrations.
With this in mind, the infrastructure team focused on a roadmap for completing CI validation of both RL10 and Gazpacho.
Then deploying to our internal lab before moving on to the upgrades of the first of our customer systems. We expect to be ready for this last stage in September 2026 and have already successfully upgraded our own internal test systems to validate the releases.
Support for Arm64
Over recent years the Arm architecture has emerged as a critical component of HPC-AI cloud infrastructure. Throughout this time the OpenStack community has maintained Kolla and Kolla-Ansible support for Arm, but often on a best-effort basis.
StackHPC has been working to change the game for Arm support. Thanks to the backing of multiple StackHPC customers, combined with our own R&D investments, the Arm architecture is now also supported in
Kayobe and the level of testing and validation performed on Arm software builds has been significantly increased. Thanks to a generous hardware donation we are able to run our own builds, test and development infrastructure for Arm.
We don't plan to stop there. StackHPC plans to continue to advance Arm support for our clients and for the OpenStack community. If you are evaluating the addition of Arm servers to your infrastructure we are ready to help you.
Migrating away from OVS-ML2 to OVN
There has been significant demand from customers using ML2-OVS to migrate to OVN, for which community proposed tools were explored, though the current methods don’t appear to support non-downtime migration.
It was decided that the migration path would only be made available from Gazpacho but it remains a product and business goal to provide a reliable and low impact path for customers migrating away from ML2-OV to OVN.
Platforms Update
Our Platforms team has seen some significant changes in recent months, with new members bringing in a range of valuable experience.
These new perspectives were key to the decisions made over the design summit, and emphasis was placed on individuals taking ownership of better-defined components of Azimuth, to parallelise progress towards overall product goals.
Over the coming months, Azimuth users will see the benefits of this as specific feedback is directed towards component leads with the authority to make changes happen.
Before the Summit, our support engineers surveyed customer deployments of our Slurm Appliance and Azimuth platforms. This informed discussions on what users and operators would like to see.
It was positive that all supported Azimuth customers use our Git-ops pipelines for Azimuth staging upgrades, and suggestions were made to reduce false positive testing results.
Several customers have expressed interest in contributing to upstream development for Azimuth, but have found that documentation for certain components can be sparse. A good place to start would be learning to deploy their own apps through Azimuth.
In the meantime we will look to improve our documentation, but a full contributor guide remains a more aspirational goal.
The June Azimuth release brings the much anticipated migration of tenant clusters from the archived Ingress NGINX to our chosen replacement - Traefik Ingress.
This won’t change the ingress controller on existing clusters. They will have to be upgraded using new cluster templates published in this release, which will uninstall the NGINX addon and replace it with the Traefik addon.
This process will incur some downtime for services deployed behind the ingress controller as the new controller is installed and loadbalancers are reprovisioned.
The Traefik addon enables the kubernetesIngressNGINX provider by default, which is designed to give users access to NGINX-specific annotations. It’s worth noting that ensuring compatibility with
arbitrary Ingress resources deployed in user clusters is out of scope for Azimuth and should ideally be tested before migration.
Azimuth 2026.7 brought support for Kubernetes 1.36, AMD GPUs, and various fixes for recent local privilege escalation vulnerabilities in Azimuth Kubernetes, Slurm and other Azimuth platforms.
Azimuth 2026.8 is due to release imminently, and brings several exciting new features. Kubernetes and other Ubuntu based platforms will now be based on a Ubuntu 24.04 Noble instead of 22.04 Jammy.
Support has been added for single-node Kubernetes control planes, setting maximum platform lifetimes and rotating control plane certificates in the Azimuth UI. Lastly, Headlamp has been adopted in place of the now defunct Kubernetes dashboard.
CVE Watch
The flurry of CVEs continues with seemingly increasing pace in recent months, driven by the rise of increasingly efficient AI-based vulnerability discovery tools,
software supply chain attacks having graduated from novelty to useful strategy and the reliance on interconnected open source libraries and dependencies.
We continue to remain committed to providing timely updates and mitigations to our customers as each new CVE becomes visible to us and to refine and improve our processes for timely communication.
CopyFail and DirtyFrag
CVE-2026-{31431, 43284}
Of particular concern have been a series of vulnerabilities affecting the Linux kernel, starting with CopyFail, which came to light at the end of April. We considered this to be a critical vulnerability in the context of Slurm,
where many users may not be fully trusted. The proof of concept script allowed privilege escalation, and claimed container escape was possible.
We shared a tested mitigation method with our Slurm customers within 24 hours of the vulnerability being shared publicly, and followed up to Azimuth customers the next day. Once patched kernels were available, we released updates for the Slurm Appliance and Azimuth.
A similar vulnerability named DirtyFrag followed the next week and allowed us to further refine our processes.
Vulnerabilities in OpenStack Keystone
CVE-2026-{42998, 42999, 43000, 43001, 44394}
In late May, five related Keystone vulnerabilities were found which allowed for authenticated users to escalate privileges to cloud admin under certain circumstances.
As stakeholders in OpenStack projects, we receive embargoed information for vulnerabilities and were able to prepare patched Release Train images, including backports to older OpenStack versions, ahead of the publication of these CVEs. This enabled customer systems to be protected immediately when the embargo lifted.
CVE-2026-46333
Giving unprivileged users access to files normally only accessible to the root user, resulting in possible information disclosure as well as a way to steal SSH keys and elevate privileges. Affects Kubernetes clusters in Azimuth and considered critical for Slurm clusters.
CVE-2026-46331
A local root privilege escalation vulnerability exploiting a flaw in the kernel act_pedit module to corrupt the page cache. Again this was of particular concern for environments with multiple users who are not necessarily trusted, such as Kubernetes and Slurm.
CVE-2026-64600
A flaw in the kernel affecting XFS filesystems used by default in Rocky Linux. A race condition in the kernel’s XFS copy-on-write path allows an unprivileged user to overwrite files on disk and escalate to root privileges. Critical for Slurm clusters,
Azimuth was unaffected due to XFS not being the default filesystem for Ubuntu.
CVE-2026-64531
A flaw in the Open vSwitch (OVS) subsystem which allows local privilege escalation. Rocky Linux 8 Slurm clusters were unaffected, but this was considered critical for Slurm clusters on Rocky Linux 9, and of medium severity for Kubernetes user clusters in Azimuth and Magnum.
CVE-2026-4349
Another Linux kernel flaw resulting in a local privilege escalation by using use-after-free bug present in the kernel for 15 years and as such affecting essentially all Linux distributions. Again, systems running user-provided code such as Slurm systems or Azimuth are at risk. As it does not depend on any specific kernel subsystem,
there is no mitigation so the only option is patching and rebooting into the new kernel.
CVE-2026-46242
A cousin to GhostLock, it relies on a flaw in a different part of the Linux kernel – in this case the eventpoll subsystem – but results in the same risks: local privilege escalation. One more for our Slurm customers and those providing shared machines to worry about.
Affects Rocky Linux 9 and 10 as well as Ubuntu 24.04 (and 26.04), but not the older Rocky Linux 8 and Ubuntu 22.04. Another vulnerability with no mitigation available.
Mitigations for the above vulnerabilities were shared promptly if available, and added by default to StackHPC published images. Once released, patched kernels were incorporated in place of the original mitigations.
From the Blog
How SMART are you?
Published 21 July 2026, by Dawud Mehmood
Dawud delves into a new updates to our SMART disk monitoring, making use of a Python-based collector that brings a host of improvements over the previous shell-scripts.
Read the full post.
StackHPC at ISC
Published 29 June 2026, by Stig Telfer, John Taylor, Steve Brasier and Seunghun Lee
Amid the heat wave across Western Europe, the StackHPC team headed to Hamburg for the International Supercomputing Conference (ISC), the annual gathering of all things HPC in Europe and beyond.
Read the full post.
Case Study: The Edinburgh International Data Facility
Published 9 April 2026, by John Taylor
Read about StackHPC’s contributions to the state-of-the-art data analytics and storage service at EIDF.
Read the full post.
Keep an eye on our LinkedIn, or the blog page of our website for the latest posts.
Parting words
Thank you for taking the time to read this edition of Navigating Upstream!
We always welcome any feedback and suggestions.
If you’d prefer not to receive future editions, you can opt out at any time using the link below or with a simple reply. Otherwise, we look forward to keeping in touch.
– The StackHPC Team
Reach out to us via Bluesky,
LinkedIn or directly via
our contact page.