How OpenStack Reviews and Mentorship Encouraged My Growth in Open Source

When I was first starting to think about what I wanted to do with my life, I wanted it to be meaningful, and I felt it would be related to computers. The ALX (African Leadership Xperience) program grounded me with the fundamentals of coding, while the Fellowship by Major League Hacking gave me my first introduction to open-source development. Soon, I discovered that I could have a positive impact on major organizations by contributing my time and talents towards open-source projects. I wouldn’t be re-inventing the wheel, I’d be pulling onto an established superhighway.

Just like with driving, I first needed to know how to operate a motor vehicle and learn the various rules of the road – in this case, the norms and needs of large organizations and the software stacks they rely on. Fortunately, through MLH, I not only learned but also found a role at G-Research OpenSource Software (GR-OSS), where I now work in the orbit of OpenStack.

OpenStack is an open-source cloud computing platform that provides Infrastructure-as-a-Service (IaaS). Think of it as the software that powers many public and private clouds – it gives you the ability to manage compute, storage, and networking resources through APIs and a unified interface, much like AWS or Azure, but open-source and self-hosted.

I’ve learned a lot from working with the people who build, operate, and iterate OpenStack to make it so successful. Looking back at how familiar I have become with OpenStack/Ironic concepts like the state machines, BMC protocols, IPA agent, cleaning vs servicing – it’s wild to think I had to Google what “bare-metal” meant when I got my MLH acceptance letter two years ago.

I’m so proud of the growth so far and excited about what’s still to come. I’m thankful for the mentors, the people I have been able to meet, the experiences I’ve learned from, and even the cool expressions and shorthands I had to note down back then but have come to understand and use today myself.

My name is Afonne-Cid Paul Onyedikachi (often just CID). I work in and around OpenStack, particularly Ironic – the bare metal provisioning service.

It has now been two years, and this article is about how I found my footing as an open-source contributor turn maintainer with the GR-OSS team.

My hope is that my story helps you attract, train, and retain emerging talent in your organization. I also hope it nudges other early-career technologists to start contributing to open source and stick with it, whether they come in through a program like MLH, a hackathon, or through sheer curiosity.

Why I Started Contributing to OpenStack

OpenStack is a great place for learning, especially with mentorship. Its community is respectful of emerging talent, and there are plenty of people willing to explain “why” things are the way they are. It is also modular, built from multiple services that work together, so there are plenty of opportunities to find places to apply your particular talent:

These Services Include:

Ironic – Bare metal provisioning service (what I work on!)
Nova – Compute service that manages server lifecycles (launching, scheduling, destroying VMs)
Neutron – Networking service that handles virtual networks, routers, firewalls, and load balancers
Cinder – Block storage service for persistent volumes attached to VMs
Glance – Image service that stores and retrieves VM disk images
Keystone – Identity service for authentication and authorization across all services
Swift – Object storage service for storing and retrieving unstructured data
Horizon – Web dashboard for managing all OpenStack services
Heat – Orchestration service for deploying entire application stacks
Ceilometer – Telemetry and metering service
And many more here.

How OpenStack Services Work Together

When integrated, these services create a complete cloud platform. For example, when you launch a VM:

Horizon (Web UI) sends your request to Nova
Nova authenticates with Keystone
Nova asks Neutron to create a network
Nova retrieves the OS image from Glance
Nova Scheduler selects a target compute host (or bare metal target via Nova’s bare metal integration)
Nova Compute prepares the instance on the selected target
If the target is bare metal (where Ironic hooks in), using the Ironic virt driver, Nova Compute calls the Ironic API to deploy/provision the physical node (handled by ironic-conductor)
Cinder attaches any required storage volumes (if applicable)
The instance starts running with all resources connected

Each service can work independently, but the real power comes from their integration – a unified API (openstack server create) that orchestrates complex infrastructure provisioning behind the scenes. I didn’t know about any of these services or tools when I got started, and when everything works as it’s supposed to, you shouldn’t necessarily need to be aware of them either.

During MLH, I worked on the Ironic Bug Dashboard, a tool to get a quick preview of new and old bugs and RFEs filed against the Ironic and adjacent projects, with their statuses as well as assigned importance. This was my introduction to the Ironic ecosystem – learning about the various projects, understanding common issues, and getting familiar with the project team. It helped me understand not just what was commonly going wrong, but also how the different services were supposed to work together. After the MLH fellowship, I received an offer to join the GR-OSS team and began contributing to the core Ironic project.

I got into reviewing other people’s code. It was scary at first, as I felt totally unequipped to evaluate what other people, many with years more experience, had written. But under the guidance and mentorship of my manager, Jay Faulkner, I gained practice and, later, confidence. I began to feel better about reviewing code. Sometimes I’ll include my opinions and votes; other times, I just learn. Working with Jay made it easy to know when it was appropriate to do what.

Why Ironic Is Particularly Meaningful to Me

Ironic is about bootstrapping infrastructure from raw hardware. The project held a sort of personal resonance to me and my experience, as I, too, was trying to build a career in programming. Although I’d like to imagine I wasn’t starting from absolute zero, I needed all the help I could get, and working with feedback from the community, I was able to quickly contribute meaningfully.

My mentor encouraged me to start here (OpenStack’s bare metal provisioning service, responsible for managing and provisioning physical machines through a centralized control plane), as it was a strong on-ramp into OpenStack; real-world production engineering problems, and plenty of opportunities to contribute in ways that matter.

Impact in Ironic

The OpenStack/Ironic community is incredibly welcoming and collaborative. I can’t really remember a time I asked a question and heard crickets or felt like I asked a stupid or obvious question (even when it feels like I do sometimes :D). In fact, Jay once told me that the only stupid question is the one that never got asked. The code review process, the patient explanations during meetings, and the collaborative problem-solving culture are what transformed me from an individual contributor into a maintainer. Beyond the direct mentorship of Jay Faulkner, I got help from lots of contributors and maintainers who made my growth as an engineer possible.

The OpenStack/Ironic community is on IRC on the OFTC network, in the `#openstack-ironic` channel (connect via `ircs://irc.oftc.net:6697`).

My Specific Areas of Impact

Alongside numerous other features, documentation fixes, and improvements across the Ironic project, below are a few contributions I am especially proud of, spanning four release cycles: Dalmatian 2024.2, Epoxy 2025.1, Flamingo 2025.2, and Gazpacho 2026.1 (upcoming at the time of writing).

Runbooks

One of my first and best works yet is Runbooks.

This is a feature that provides a structured, step-by-step way to define and execute a sequence of actions on a node during cleaning and servicing operations. It enables both simple and complex procedures to be carried out in a consistent, predefined, and automated manner.

Inspection Rules

Inspection Rules is another feature that already existed in the now-deprecated and retired Ironic-Inspector that I worked on migrating into the Ironic repository.

Eventlet Removal

Eventlet is a concurrent networking library that almost every open-source project has been using directly or indirectly for at least a decade. And it worked well all this time. But Eventlet relies on monkey-patching internal behaviors of the Python standard library, such as the way threads work, etc.

As the Python version continues to change, right around Python 3.12 was the inflection point; the internal mechanisms have changed so much that compatibility issues started arising, and the small number of project maintainers of the project couldn’t possibly attend to all of these, so OpenStack made the removal of Eventlet OpenStack-wide a top priority.

I worked on migrating the Ironic-Python-Agent and some parts of the Ironic repo away from Eventlet.

Kea DHCP Support (Abandoned)

It’s not only about the changes that made it in. Sometimes there can be value in spotting something that doesn’t fit or that no longer belongs.

I added support for Kea DHCP as an alternative DHCP backend to dnsmasq.

The goal was an API-driven DHCP server we could manage programmatically. Turns out, the critical configuration hook libraries needed for dynamic updates (adding or removing hosts and leases via API) were proprietary and tied to ISC support contracts, which killed the value proposition.

It never got to the finish line. The bug in dnsmasq that originally made it unreliable got patched, and without Kea’s key hooks available, the work no longer justified itself.

Still, it wasn’t for nothing. I walked away with a much deeper understanding of DHCP behavior in production, how dnsmasq fits into the stack, and what an “API-driven DHCP backend” truly requires.

Other Notable Contributions

Timely acknowledgment of newly reported potential bugs (pending triaging) and attention to new feature requests encourage continuous feedback from operators as well as demonstrate that the community is active, responsive, and values their input, which is essential for maintaining trust and engagement in an open source project of this scale.

I have triaged over 200 bugs/RFEs (and counting) as the de facto bug deputy. It is an honor and a particularly exciting contribution towards the refinement of various critical components of the Ironic and Ironic-adjacent projects, namely: ironic-python-agent, ironic-python-agent-builder, sushy/sushy-tools, networking-generic-switch, bifrost, and more.

I also contributed code to support disabling specific boot modes during deployment/enrollment operations, requested around June 2024 at the CERN Baremetal SIG meetup. (I included this one for bragging rights, I mean, it’s CERN, the world’s leading particle physics laboratory and birthplace of the World Wide Web!)

Over my first two years on Ironic, I completed 505 code reviews/approvals and contributed 194 commits across 5 projects. That works out to roughly 1 review per workday over two years (about 500 workdays), while steadily shipping changes alongside reviews.

What’s Next?

On Ironic, the goal is simple: fewer bugs, happier operators, clearer and more current docs, new features that stay backward-compatible, and ultimately make the contributor path easier for the next wave of people joining the project. Those should be the goals of any open source software project!

On the personal side, I have goals to gain more technical depth and range to be able to have meaningful discussions generally as a software engineer, and especially as an open source and OpenStack Developer. I also want to present my work and the importance of all open source work to others in the tech community, through attending and speaking at industry conferences. I look forward to meeting more of my collaborators in person, so we can move beyond screen-mediated interactions and maybe grab a coffee together!

Connect With Me

Twitter/X: @cee_eye_d
LinkedIn: cidelight