Stephen Finucane (Fin-oo-can)

Image by John Reed / Unsplash

Blog

  • I previously presented on our work to bring OpenAPI to OpenStack as part of the 2024 OpenInfra Summit Asia, the slides for which you can find here. Since that talk, another release cycle has come and gone and our work has continued to progress. Below is a summary of the current “state of play” for OpenAPI support in OpenStack and a reminder of our long-term goals in the area.

  • I’ve recently found myself once again working on the OpenStack Cinder CSI Driver and the Operator that OpenShift uses to deploy this. This work has inspired me to improve my knowledge of how the Cinder CSI Driver - and CSI drivers in general - work. Below is my current high-level understanding of both as well as a quick summary of changes we are making to the Cinder CSI Driver Operator in OpenShift 4.19.

  • It’s an often overlooked fact that OpenStack has two wholly different mechanisms for provisioning block devices for instances. While most people are aware of the Block Storage service, Cinder, not everyone is aware of or gives much thought to the various types of block devices or “ephemeral” storage that the Compute service, Nova, is able to provide. This article serves to provide a high-level overview and comparison of these two different mechanisms, including examples of how you can use them and some hopefully (interesting) asides.

  • After seeing a few too many availability zone-related issues popping up in OpenShift clusters of late, I’ve decided it might make sense to document the situation with OpenStack AZs on OpenShift (and, by extension, Kubernetes). This is the second part of two. The first part provided some background on what AZs are and how you can configure them, while this part will examine how AZs affect OpenShift and Kubernetes components such as the OpenStack Machine API Provider, the OpenStack Cluster API Provider, and the Cinder and Manila CSI drivers.

  • In the Dalamation (2024.2) cycle, we’re working on adding OpenAPI schemas for a number of the OpenStack services. As part of this effort, I’ve had to learn more than I would like to know about how various services’ API machinery works. The below is a quick summary of how the mapping of URLs (or rather, paths) to API controller methods works in Nova (and Cinder, Manila and other projects that have copied or inherited Nova’s patterns). This is very much inside baseball and probably not useful outside of OpenStack, since we’re using older libraries - namely Routes, Paste, and WebOb - that have been mostly superseded by new libraries like Flask, Falcon, or Starlette. Still, maybe it’s useful for someone.

Talks