This document summarizes the changes between commit 38b5e63cf3d56df4568a9640e40ea3283ada7b95 (previous iteration) and the current HEAD (10487db642cf5580d20016dde25ab1423b0c1ad7). The spec underwent significant expansion with 491 insertions and 168 deletions, adding substantial detail on future work, implementation details, and use cases.
The placement service in OpenStack is an inventory management system.
Placement models the available resources in an OpenStack cloud as a set of resource providers in a tree structure. Each resource provider has inventories of consumable resource classes such as CPUs, memory, disks, and capabilities known as traits.
# Watcher 2026.1 Gazpacho PTG Report
## Executive Summary
The OpenStack Watcher project held its virtual Project Teams Gathering (PTG)
from October 27-31, 2025, to plan the 2026.1 Gazpacho development cycle. The
event brought together key contributors including sean-k-mooney, dviroel,
rlandy, chandan, jgilaber, amoralej, and efoley to address critical technical
debt, modernization efforts, and strategic improvements. The PTG resulted in| *Watcher 2026.1 Gazpacho virtual PTG | |
| *DO NOT USE TRANSLATION TOOLS IN THIS ETHERPAD!!!! (ノ ゜Д゜)ノ ┻━┻ | |
| *不要在这个ETHERPAD中使用翻译工具! | |
| To translate this etherpad, please follow these easy instructions: | |
| 1. Look in the above toolbar and click the '</>' ("Share this pad") button | |
| 2. Click the "Read only" checkbox at the top of the dialog box | |
| 3. Copy the URL that appears in the "Link" box | |
| 4. Open that URL in a new browser tab or window | |
| 5. Use your translation tools of choice in the new window | |
| Thank you! |
Note: This document is a working implementation guide and will not be committed
to the repository. All permanent documentation will be in reStructuredText format
under doc/source/contributor/.
This document provides a concrete, phased implementation plan for code quality improvements. The plan is structured around deliverable outcomes rather than incremental tooling, with each phase being self-contained, self-testing, and self-documenting.
This document outlines a concrete, incremental plan to improve code quality across the repository with a focus on:
- Eliminating wildcard (
*) imports with a single allowed exception - Eliminating relative imports in favor of absolute imports
- Enforcing import style and symbol access patterns
- Eliminating non-essential use of reflection helpers (
getattr,hasattr,setattr) including common Django patterns
Version: 1.0
Date: October 2025
Status: Planning Document
This document outlines a comprehensive, multi-phase approach to introduce functional testing to the Watcher project, adapting proven patterns from OpenStack Nova and Placement while accounting for Watcher's unique architecture. The plan includes test reorganization, fixture development, base test infrastructure, Gabbi-based declarative API testing, and contributor documentation.
This document provides a comprehensive analysis of the OpenStack Placement project's Gabbi-based functional test infrastructure. It is designed to enable replication of this pattern in other OpenStack projects, with particular focus on fixture structure, database setup, API application initialization, and test execution.
Key Technologies:
- Gabbi: YAML-based declarative HTTP testing framework
- oslo.test/oslotest: OpenStack test framework base
- oslo.db: Database abstraction and fixtures
Version: 1.0
Date: October 2025
Author: AI-assisted analysis of Nova functional test infrastructure
This comprehensive guide documents Nova's functional test infrastructure and provides a blueprint for replicating this pattern in other OpenStack projects. It covers fixture architecture, RPC/messaging, database management, external service mocking, and CI/CD integration.
A frequent topic of discussion for OpenStack administrators is how to properly configure CPU allocation to balance performance and density. This blog post, inspired by a recent internal chat, will walk you through the key configuration options in OpenStack Nova for managing CPU overcommitment, with pointers to the official upstream documentation.
CPU overcommitment allows you to present more virtual CPUs (vCPUs) to your instances than the number of physical CPU cores available on the compute host. This is a common practice in virtualized environments, leveraging the fact that most instances don't use 100% of their assigned CPU all the time.
It's important to remember that in Nova, CPU overcommitment only applies to instances with a shared CPU policy (hw:cpu_policy='shared'). Instances that require dedicated CPUs (hw:cpu_policy='dedicated') get exclusive access to physical cores, and t