Major Feature Highlights

• Track/manage BIOS & EFI settings via --bootmode
• Future-proof stricter py3.14+ event_loop use.
• Several major fixes
• Refactoring in several areas

Development Statistics

• 5 x peer-reviewed Gerrithub patch-sets
• 11 x changed files with 113 additions and 61 deletions.
• Thank you to our contributors for this release: Alekos Atsalakis, Gonza Rafuls, Will Foster
• This is the 22nd release of QUADS since 23-June 2016 when 1.0 was released

Full Change List

• A full list of changes can be found here

As always please read the full release notes to be kept abreast of any breaking changes or new configuration options.

First let’s look at some pictures!

Let’s dive into the details, everything is tentative even the dates but this should give you a much better idea of where development is headed into 2026.

QUADS Project Roadmap: 2026

This roadmap outlines the progression from infrastructure hardening (BIOS/EFI) to architectural flexibility (Plugins), followed by a major expansion into Hybrid Cloud and User Experience (UI/SSO).

Current Status: v2.2.4 (Released 2026-10-30)

Detailed Milestone Breakdown

v2.2.6: The Infrastructure Update

• Target: End of February 2026
• Theme: Deepening hardware control.
• Key Features:
  • bootmode Automation: Introduction of full lifecycle management for BIOS and EFI states. This removes manual intervention for switching boot modes, critical for automated provisioning workflows.
  • Major Fixes: Accumulation of stability patches post-2.2.4 to prepare the codebase for the 2.3 architectural shift.

v2.3.0: The Modular Shift

• Target: End of March 2026
• Theme: Extensibility, Design Simplification.
• Key Features:
  • Plugin Architecture: Decoupling core logic from extensions. This is a pivotal release that allows community and enterprise users to write custom scheduling or provisioning logic without forking the core QUADS codebase.
  • Badfish Refactor and Migration: Removing and refactoring codebase to use the upstream Badfish RPM once it is accepted and available into Fedora project upstream.

v2.3.2: Stabilization Phase with Network Features

• Target: End of May 2026
• Theme: Reliability.
• Key Features:
  • Maintenance: Specifically targeted at stabilizing the new Plugin Architecture introduced in 2.3.0.
  • Tech Debt: Address any regressions found during the 2.2.x -> 2.3.x transition.
  • Network Automation: Enhance --modify-switch-conf to allow day one, custom per-port bonding configurations and for move_and_rebuild to roll them back properly.

v2.3.4: The Hybrid & Security Preview

• Target: Mid-July 2026
• Theme: Expansion beyond bare metal.
• Key Features:
  • Hybrid Cloud Preview: Initial support for provisioning and managing resources on AWS and IBM Cloud alongside local hardware.
  • Auth Preview: Implementation of User SSO and Token management backend. This lays the groundwork for the secure multi-tenant UI coming in the next release.

v2.3.6: The User Experience Overhaul

• Target: Estimated end of September or Q3/Q4 2026
• Theme: Accessibility and Self-Service.
• Key Features:
  • UI Phase 2: A major frontend update leveraging the new APIs.
  • User Portal: Full integration of the SSO backend (from 2.3.4) allowing users to log in, view and manage scheduled assignments, and self-schedule resources.
  • Admin Scheduling UI: A graphical interface for administrators to manage the queue and resource allocation, replacing CLI-only workflows for common tasks.

Strategic Observation

This roadmap demonstrates a clear maturation curve for QUADS:

1. Q1 2026: Solidifying the “Metal” layer (BIOS/EFI).
2. Late Q1 2026: Opening the “Logic” layer (Plugins).
3. Q2 2026: Expanding the “infrastructure” layer (Hybrid Cloud, Network Bonding).
4. Q3 2026: Polishing the “Human” layer (UI/UX).

Major Feature Highlights

• Per-Server hardware details page, auto-generated and updated dynamically

• New dynamic network connectivity diagram and topography map per environment

• Modernized heat map and calendar visuals design

• Added disk type, size, and count to the available UI
• Added Network vendor and speed to the available UI

• Major refactor of move_and_rebuild.py
• Several tools were promoted to CLI commands
• Replaced argparse with click for CLI commands
• Added --ls-cpu and --ls-gpu in place of --ls-processors
• Host metadata can be completely removed now via --rm-host-metadata
• Removed unused driver types
• Lots of cleanups and other fixes

Development Statistics

• 56 x peer-reviewed Gerrithub patch-sets
• 108 x changed files with 4,794 additions and 1,556 deletions.
• Welcome new contributor @AlAtsal
• Welcome back returning contributor @sjug
• This is the 21st release of QUADS since 23-June 2016 when 1.0 was released

Full Change List

• A full list of changes can be found here

As always please read the full release notes to be kept abreast of any breaking changes or new configuration options.

In addition to our Python client library or accessing the restful API directly via curl you can now use Ansible to directly self-schedule and receive systems from a QUADS server.

Features

• Performs all self-service steps: registration, login, host discovery and scheduling
• Allows scheduling multiple hosts or passing additional cloud values e.g. qinq: 1 or nowipe
• Allows setting a host model preference order, or use all if you don’t care
• Supports listing available servers or scheduling specific servers you want
• Supports listing your current, active assignments only
• Generates list of scheduled hosts and authentication details to a local file
• Generates helper commands for querying assignment validation status and terminating the assignment via it’s assignment_id

Quickstart

Clone the ansible-quads-ssm repository and adjust quads_config.yml appropriately.

git clone https://github.com/quadsproject/ansible-quads-ssm
cd ansible-quads-ssm && vim quads_config.yml

Ensure you have ansible, ansible-core and jq installed

dnf install ansible ansible-core jq

Off you go then!

ansible-playbook quads_self_schedule.yml -e "workload_name='My Test Workload'"

Find all the documentation and details here.

Major Feature Highlights

• BIOS boot order management is now configurable, with the default now being foreman but still supporting director boot mode for OpenStack workloads still using ironic-based PXE orchestration. This provides the following tenant and operator benefits via this feature.
  • Reduction of bare-metal systems delivery time by 25-30%, eliminating a reboot cycle if using foreman_default_boot_order: foreman which is our default
  • Reduction of tenant post-delivery and day zero orchestration needs by eliminating the need to perform badfish --boot-to calls for re-provisioning in Foreman (it’s enough to mark for build and reboot now).
• Additional performance improvements be removing some sleep mechanics if boot order matches what’s requested
• Removed a few unneeded dependencies and files
• Additional fixes to the self-scheduling API

Development Statistics

• 25 x peer-reviewed Gerrithub patch-sets
• 31 x changed files with 508 additions and 199 deletions.
• This is the 20th release of QUADS since 23-June 2016 when 1.0 was released

Full Change List

A full change list can be found here.

About 2.2.0

QUADS 2.2 delivers breakthrough enhancements such as the long-awaited self-scheduling API feature and GPU awareness to compliment AI workloads. This release is primarily a major feature release with a slew of fixes as well and a sleek looking dark theme for quads-web.

2.2 is the culmination of nearly a year of parallel development work and we’re really excited about releasing it to the world.

Major Feature Highlights

• New self-scheduling feature via the RestAPI! You can talk directly to the API or use our new Python client library
• QUADS is now aware of GPU devices and they can be added to the metadata model for filtering and systems selection.
• You can now use any hostname convention you like as rack, u-location and blade are part of defining new hosts
• quads-web now has a dark theme
• You can now select a different OS from the default for future clouds from anything available in your Foreman via –os and you can use –os-list to list available operating systems from your Foreman.
• Packaging enhancements: quads-server and quads-web will now auto restart after upgrading and run any database migrations for you.

Development Statistics

• 86 x peer-reviewed Gerrithub patch-sets
• 117 x changed files with 3,929 additions and 1,175 deletions
• Welcome our 13th contributor, @sjug
• This is the 19th release of QUADS since 23-June 2016 when 1.0 was released
• A full list of changes can be found here.

Breaking Changes and Migrations

• Configuration files have been split out into two new files:
  /opt/quads/conf/quadsweb.yml (UI specific options go here now)
  /opt/quads/conf/selfservice.yml (options for self-scheduling feature, disabled by default)
• Please see the Breaking Changes and Migration instructions on the official release changelog.

It all started 8 years ago during EuroPython 2017 when Will introduced me to QUADS 1.0 and how their whole client-facing inventory and UI was relying on a heavy WordPress dependency. I was adamant that if I ever joined the team I would replace WordPress with a proper Python web service.

Migration

So we started the migration process thinking that making a Jinja template for each page on our wordpress instance and making a couple of calls to the fresh QUADS 2.0 REST API would suffice but that meant a huge oversight on performance since the pages on WordPress were pre-rendered and only served by the php server. Now we have all our templates and the calls ready so we test in stage which only has 15 servers, unlike our production instance which has ~1300. All good on stage so we merge to production and we ship it. That’s when the fun began.

Ajax Requests

Now we have our new stack in the production instance and we navigate to the inventory and we are presented to a blank page that stays loading for more than 2 minutes. Unacceptable.

We are loading all the data on the flask endpoint, making a bunch of calls at one point and waiting to gather all the data so we can pass it to the Jinja template rendering. In a desperate attempt to make it better we double the Gunicorn workers to find no considerable performance improvements.

Ajax requests come to the rescue.

We realize gathering all that data before the rendering and holding the user from seeing anything loading on the page is going to scare the users away and leave them thinking the server is broken. We move all the data collection logic to ajax requests on each page expecting things would load faster but it’s only the page skeleton which loads while the gathering of the data still takes the same amount of time as before.

Lazy loading

All nice and fancy with the Ajax requests but the performance is still miserable. In comes lazy loading.

Since we had split all the ajax requests for each section and we have one section for each cloud which can be up to 100 concurrent cloud environments, we’d still have to wait for all the requests to be loaded before we can navigate anywhere else. The only sensible change to make would be to only make those requests when the user has the section displayed on their browser view port. With some javascript magic we add an observer that calls the ajax requests only when the component is scrolled to.

                    const observerOptions = {
                        root: null, // Use the viewport as the root
                        rootMargin: '0px',
                        threshold: 0.1 // Trigger when 10% of the element is visible
                    };

                    const observer = new IntersectionObserver((entries, observer) => {
                        entries.forEach(entry => {
                            if (entry.isIntersecting) {
                                const cloudName = entry.target.getAttribute('data-cloud-id');
                                updateHostsForCloud(cloudName);
                                observer.unobserve(entry.target);
                            }
                        });
                    }, observerOptions);

                    $('.cloud-table').each(function() {
                        observer.observe(this);
                    });

This reduced the number of requests significantly to only 3 requests initially, 1 for the summary and 2 others for the first 2 clouds which are rendered at the top of the page. We see a considerable improvement with this but we know there is still room for improvement.

Flask Async

Regardless of the great improvements we achieved so far we notice that if there is more than 1 user trying to load the page the responses don’t come through till the other user gets their responses. In comes Flask Async methods. 

We can now make all our endpoints async and all our ajax requests as well. This paired with a couple more workers on Gunicorn and we get a much more responsive web.

The Unwanted Requests

Now that we have Async Ajax requests, Async Flask endpoints and lazy loading requests we feel a lot more enterprise ready so we go and stress test our new QUADS web companion till we find there is one more place for improvements. The unwanted requests.

Imagine that you go to the page and the few initial requests are called but you then, out of boredom or curiosity, scroll all the way down triggering the call to all requests and before you get those responses decide to move along to another page. The browser will then say: “nah nah nah, now you sit and wait for all these requests you triggered”. With some additional javascript magic we say abort all ongoing requests if I am navigating away from this page. For that we make a global variable for each request and add a listener for `beforeunload` which gathers all those requests and calls the `abort()` method on.

        $(window).on('beforeunload', function() {
            // Abort all cloud-specific requests
            for (const cloudName in cloudRequests) {
                if (cloudRequests[cloudName]) {
                    cloudRequests[cloudName].abort();
                }
            }
            if (summaryRequest) {
                summaryRequest.abort();
            }
            if (dailyUtilizationRequest) {
                dailyUtilizationRequest.abort();
            }
            if (unmanagedRequest) {
                unmanagedRequest.abort();
            }
            if (faultyRequest) {
                faultyRequest.abort();
            }
        });

Takeaways

The journey from WordPress to a Python-based web service revealed critical insights about scaling web applications for production environments. Here are the essential lessons learned:

• Performance optimization is a step-by-step process, not a one-time fix

This migration story demonstrates that web performance optimization requires an iterative approach with multiple techniques working together to achieve substantial improvements. Each implementation—from Ajax requests to request abortion—addressed specific performance bottlenecks that weren’t apparent until the previous issue was solved.

• User perception matters more than backend speed alone

The initial approach focused solely on backend optimization, but the breakthrough came when prioritizing user experience through progressive loading techniques. Even when data retrieval remained slow, showing users the page skeleton immediately created a more responsive feeling application that kept users engaged rather than frustrated by blank screens.

• Scale testing in production-like environments is essential

The dramatic difference between stage (15 servers) and production (~1300 servers) environments highlights the danger of assuming performance will scale linearly. What works perfectly in a small environment can completely fail when faced with real-world conditions and loads.

Modern web development requires multiple optimization techniques working together

The final solution incorporated several complementary approaches:

• Ajax requests for progressive loading
• Lazy loading to prioritize visible content
• Asynchronous Flask endpoints for concurrent processing
• Request abortion to prevent wasted resources

No single technique solved the performance issues entirely, showing that comprehensive optimization requires a layered strategy rather than seeking a silver bullet.

Major Feature Highlights

• New tenant contact tool: notify_tenant.py
• New commands --ls-notifications and --mod-notifications are available
• lab_name now allows you to set your QUADS environment name within the quads-web service
• Visual heat-maps are now rendered in-band of flask / quads-web
• Visual heat-maps should render the full month now
• quads-web now uses async to speed up content renders
• quads-web Ajax lazy loading will abort to load other link navigation faster
• quads-web now loads jquery assets locally and does not require access to the internet
• quads-web and its /available endpoint for searching system availability can now have its Date Range manually edited.
• Several other bug fixes

Development Statistics

• 23 x peer-reviewed Gerrithub patch-sets
• 31 x changes files with 930 additions and 484 deletions
• This is the 18th release of QUADS since 23-June 2016 when 1.0 was released
• Please consult the full change-log of differences between the last release and current release for details on all fixes and enhancements.

Tis the season.  Be excellent to each other, and party on.

Major Feature Highlights

• Major quads-web UI performance improvements using Ajax / lazy loading
• quads-web updates for /available UI
• quads-web navigation bar is now rendered at service start time
• Several major cloud define and notifications bugs fixed after running 2.1.0 for quite some time in production
• quads –foreman-rbac now runs from the move_and_rebuild phase
• QUADS Badfish library will now auto unmount ISO media for Dell systems
• verify_switch_conf fixes
• lshw and metadata import fixes and updates
• Refactoring to use SQLAlchemy DB calls in some places over direct API for heavy lifting
• Contributing sandbox steps remove container orchestration, focus on venv workflows for easy testing
• Pre-commit hooks are now in place for development workflows

Development Statistics

• 36 x peer-reviewed Gerrithub patch-sets
• 112 x changes files with 2,558 additions and 2,049 deletions
• This is the 17th release of QUADS since 23-June 2016 when 1.0 was released
• Please consult the full change-log of differences between the last release and current release for details on all fixes and enhancements.

Be excellent to each other, and party on.

What’s Changed?

Over the course of ~6 months of parallel development up to and through the 2.0 release of QUADS we rewrote all of the functionality previously provided by WordPress (automated wiki/inventory/etc) in pure Python, Flask and Jinja2.  This resulted in some of the following changes and improvements:

• Complete removal of the WordPress component/dependency from QUADS
• Removal of large parts of the code-base dedicated to automating the sync of QUADS status/wiki/inventory over the WordPress XMLRPC/Python API.
• The quads-web service will now handle our dynamic inventory and wiki component directly via Flask
• 13 x commits, 74 changed files with 1,724 additions and 2,045 deletions
• Full release notes here

Major Feature Highlights

• Full removal of WordPress as the QUADS automated wiki component
• Removal of large parts of the code-base dedicated to automating the sync of QUADS status/wiki/inventory over the WordPress XMLRPC/Python API.
• The quads-web service will now handle our dynamic inventory and wiki component directly via Flask
• Wiki content and navigation menus are now instantly generated
• Ability to serve your own static content and menus is documented here
• Huge performance improvements in quads –regen-heatmap using asyncio
• Much easier adoption for new users

Architecture Overview

This is what the QUADS 2.1 architecture looks like now:

Breaking Changes and Migrations

System Requirements

• A supported version of Fedora Server is required if using our RPM packages
• Recommended VM with 8 x vcpu and 8 x GB of memory.
• For full features, an existing Foreman that manages your DNS, DHCP, PXE and systems lifecycle

Migrating from 1.1.8

• You should follow the upgrade instructions from 2.0.5 for the steps and data migration needed to move to 2.1.

Migrating from 2.0.5

• Several conf/quads.yml changes have been completed removed.
• Nginx vhost configuration files have been simplified, see upgrade notes.

See the bottom of the changelog for full details