First Week at Libvirt

Hello!

This is my second blog post from the GSoC internship with Libvirt series. It is also the first post since I started the internship.

MORE ABOUT THE PROJECT

Libvirt is an open-source API, daemon and management tool for managing platform virtualization. It provides an hypervisor independent API for managing compute resources on physical hardware/systems. i.e it provides tools for creating, managing virtual machine among many other uses.

For the next twelve weeks, I will contributing to lcitool, which is a CI tool used internally by libvirt developers to create virtual images and container templates. The goal is to extend lcitool functionality to include the ability to build images using the container templates and perform tests in the containers.

This addition is as a result of the upcoming changes to the CI/CD for free tier users on gitlab.com. Due to this changes, there is a going to a need to run some of the container-based tests locally, and this project helps to solve this problem.

The container build will be done by using a Python container library binding called podman-py

THE STRUGGLE IS REAL

I looked into the Python binding for Podman's API to figure out how container functionalities can be performed from a Python script. Apparently, there is a need to start a listening service for access to Podman's API in order to build images, run containers and others.

Also, libvirt.git contains an helper script that is used to pull container image from Gitlab, and perform build and tests on the container. Part of my project is to provide an option to build the container image locally rather than pulling from a remote repository, and so I dived into the script in order to better understand my project. It turns out, there was nothing in it to help me for the initial stage.

HOW I GOT BETTER...

During the week, I had a call with my mentor to explain some questions I had and map out the deliverables for the next week.

The next step was the research phase, I read about processes in linux, then I proceeded to check on how to do it with Python using the inbuilt subprocess module in Python.

After my research work was done, coding sessions began on integrating how to spawn a Podman API listening service using lcitool. I soon found out that the state of the process created with subprocess.Popen by the launcher class was not constant, and with every call to the command, a new process is created in the process table; and there was no way to kill an already spawned process (in the launcher class) because state does not persist across multiple class call.

I tried to use the Singleton design pattern (it provides an instance of a class across multiple class call), but it didn't work because what was required was the ability to keep an object state even after class call had ended at the module level, but what Singleton offered was the ability to get a single instance of a class as long as the call at the module level has not ended.

I also tried the Borg design pattern but I didn't really understand the pattern, or know if it was helpful in my case

I was able to achieve spawning Podman API listening service with lcitool by using Python's subprocess module to call podman system service --time=0, and then print out the process id (pid) to the terminal. To end the process call, the pid is passed to os.kill. This method is not efficient by any means, but it does get the job done and I hope to improve on it next week.

CONCLUSION

The best thing you can do for yourself is simplify your problems; how do you do that? Read a lot before even starting to write code. When you do start to write, have a clear idea of what you wish to get done by the end of the day.

The work I had done throughout the week gave me hope that I would be able to solve the problem in the coming week. Although I didn't get it done, I had a good feeling.

A big thanks to my mentor for helping me simplify what I had to do in the first week!