Intro
I'm excited to share that I've been accepted into the MLH fellowship program for the third time. This time, I work on OpenStack/Ironic under the guidance of the G-Research Open Source Team.
If you are interested in my previous experiences in the program, please check the posts below.
- How I prepared MLH Fellowship Application as a Career Switcher
- My Experience with Apache Airflow
- DevOps Practical Experience with Home Lab
What is OpenStack?
OpenStack is an open-source cloud computing platform that allows organizations to manage compute, storage, and networking resources. It provides an alternative to proprietary cloud platforms like AWS, Azure, and GCP, offering similar services while giving users full control over their infrastructure.
OpenStack follows a modular architecture, meaning it consists of multiple components, each responsible for different aspects of cloud management. One of these components is Ironic, which I'm working on in this fellowship.
For more details, visit the OpenStack website.
What is Ironic?
Ironic is an OpenStack component designed for managing bare metal infrastructure. It allows users to provision and manage physical servers in a way similar to virtual machines, providing greater flexibility and automation for hardware deployments.
My Works
- Writing Hardware Manager Container-Based Cleaning (75%)
- Fixing bugs and updating documenatation (20%)
- Code Review (5%)
Writing Hardware Manager Container-Based Cleaning
My mentor assigned this as my main task for the internship. I feel fortunate to work on this feature, as G-Research (the program sponsor) has wanted it for a while. I’ve spent most of my time implementing it.
Ironic Python Agent is a key actor in Ironic, responsible for preparing machines for deployment. It runs on a ramdisk and performs cleaning, inspection, and provisioning actions by performing "steps" in a given order. As you can tell, I'm going to enhance the cleaning process.
I created this issue which was approved in the Ironic Team meeting. Currently updating Cleaning tools for Ironic nodes(servers) requires modifying and redistributing the entire IPA ramdisk image. With this new feature, users will only need to update their cleaning container image, significantly simplifying the process.
When I was first assigned my main task, I had no idea where to start. But after following my mentors' step-by-step guide, I gradually gained a clear understanding. Here are some of the steps I went through.
Step 1: Deploy Devstack on AWS VM
- DevStack is a lightweight way to set up an OpenStack environment for development and testing.
- Running it on an AWS VM provides a cloud-based environment to test Ironic and Ironic Python Agent.
OpenStack development happens on remote server, which I find really enjoyable. So far, I've broken my VM 3 times so far and had to start over from scratch each time.
Step 2: Add Custom Cleaning process to the IPA RAM
- Confirm the autocleaning leave the log(Ex print("Cleaned by Satoshi"))
Step 3: Add Podman(Container) operations to the cleaning
- Integrate container operation into the custom cleaning process using Podman
Step 4: Implement a config-driven approach
- This allows users to set up container-based cleaning steps easily by modifying config files, without needing to change the project's code.
End Goal
I'm almost done with the feature implementation, but landing three PRs across different repositories is not easy.
- Add ContainerHardwareManager (PR to ironic-python-agent)
- Create Podman DIB (PR to ironic-python-agent-builder)
- Send Container Configuration to IPA(upcoming PR to ironic)
The first two are waiting for reviews and I'm about to start working on the third PR. If I manage to land all three, I'll consider this a big success.
Some Issues I worked on so far
Besides the main task, I picked up some issues.
Documentation - Create Reference Page
This was my first PR to the OpenStack/Ironic. I learned how to use development tools (Gerrit, Launchpad) and how to write commit messages for OpenStack.
I am glad I impressed my mentor with this PR.😄
Code - Code Refactoring and Log enhancement
While this wasn’t technically challenging, I’m really proud of this work because it will help future developers. During development, I initially missed making the kernel/ram image public, and the log simply stated that the image wasn’t found.
In this log enhancement, I made it much easier to spot the actual issue: a permission problem. It took me quite a bit of time to fix, but it was worth it to improve the debugging process for anyone working with the code in the future.
Conclusion
I'm grateful for this great learning opportunity provided by MLH fellowship and G-Research. A lot of learning has happened in this short amount of time. Soon, I will be implementing a feature that many companies will rely on sooner.
Happy coding!!
Top comments (0)