LIBVIRT - GSoC COMMUNITY BONDING

Over the last couple of months, I prepared and submitted a project proposal to contribute to the Libvirt organization for GSoC 2022. On May 20, I received an email from Google that my application was accepted i.e over the summer, I would be a remote software engineering intern at Libvirt.

I would be working on the Libvirt continuous integration(CI) platform which has an internal tool called “lcitool”. A Python library that enables libvirt developers to create Virtual Machine images, and container templates to get isolated build and test environments for their support projects. Over the summer, I would be making use of the container template to build container images with the help of a container library binding called “podman-py”.

Basically, I would be adding a functionality to “lcitool” that allows running container execution for building and testing using the APIs provided by “podman-py”.

Throughout the internship period, I will try to make a blog post every other week(if possible) of what I accomplished during the week. On 23rd of May, I started the community bonding/on-boarding period of the internship.

The day started with a quick email with my project supervisor, and then I picked a “bit-sized” issue on the organization’s CI repository. The developers had been contemplating making the libvirt-ci repository more Pythonic i.e to follow the Python packaging standard. It looked like an easy enough task to get my feet wet. Well, it was. Community bonding week one alone wasn’t enough to get the project merged.

Looking back now, the task wasn’t ever going to test my Python skills, it was all about Git. I quickly re-structured the repository, and I submitted a patch to be merged, it wasn’t merged because I had lumped all the changes together rather than splitting each component into a different commit.

E.g I had a directory that was nested two levels deep, a couple of .gitignore, README files. What I initially did was move the directory to the root directory, merge all the .gitignore files together, merge all the README files together, and then submit a single patch.

What I should have done, and later ended up doing was merge all the .gitignore files together and move them to the root directory, do the same with the README, only then should I move the nested directory to the root directory. This way, you have a clear separation of thought, and you can craft explicit commit messages so that there isn’t any problem when looking back at the project’s history.

I had to learn “git mv” rather than using “mv SOURCE DESTINATION”, then “git add FILENAMES” which was not too effective. I also learned how to use “git rebase” for splitting a single commit into multiple commits. It was a bit challenging, but nice. NB: Don’t checkout to a new branch during rebase. I learned that the hard way.

MOVING AND MERGING FILES WHILE KEEPING ORIGINAL COMMIT HISTORY

During the week, I gave myself a problem which was to try moving and merging files together without losing their original commit history. I.e Consider the following files;

• Changes were made to a file, “guests/lcitool/.gitignore” by Tayo and Zubair,

• Bazzan made changes to “guests/.gitignore”,

• “.gitignore” was written by Erik.

Merging all the files into a single .gitignore in the base directory while keeping the original commit history is no easy task.

This is possible by using two git branches. The files would be renamed on each branch and merged together leading to a merge-conflict that when resolved has a file that maintains the commit history.

In more detail, let the branch names be “main” and “branch”. On branch, rename “guests/.gitignore” to “file” using “git mv”. Switch to main, and rename “.gitignore” to “file”. Merge the changes from branch into main, and a file with line history preserved would result after resolving the merge conflict. You can then rename “file” back to “.gitignore”.

The downside of the method above is that it adds a lot of commits to the repository, and I decided it wasn’t worth it. I ended up having to merge all the files together without giving the history much preference.

I also researched “Ansible” because I was seeing a lot of it in the project repository. It turns out, Ansible is an Infrastructure as code. More on that in the next series.

The first week was really nice, and I look forward to blogging about the second week.

WEEK TWO AND THREE

The major highlights of the second week was getting my contribution merged, and reading about Ansible.

Throughout the week, I made continuous changes to the patches to address different issues ranging from improper indentation in commit messages, adding comments to specific patches, to getting Gitlab CI to pass. By Friday, it was all resolved and merged into the main branch. Since the core functionality of lcitool is creating virtual machine images to get an isolated environment, I explored how this was done using Ansible.

Ansible helps to tackle major problems with infrastructure using code; Infrastructure as Code.

I started delving into my project during the third and final week of the community bonding period, so there wasn’t really anything exciting to report.