Week three...
I started the this week by working on the context manager. After the last review session, I read up on context manager, and implemented a solution that made use of a context manager to start the listening service for podman API, and to manage access to PodmanClient class from the podman-py module.
Then, I refactored the build method which is used to build container image by using lcitool dockerfile command and PodmanClient().images.build method. I tried to enable real-time logging to the standard output, but it seems like there is no current support for it in the module.
The main blocker I had this week was running workload in a container. This is because it requires the ability to mount a volume. A volume can be as simple as a file/directory that is on the host machine, and it's required on the container's file directory in order to run application/process. And so I delved into podman-py documentation to figure out how to implement;
podman run --rm -it -v "/tmp/lcitool/buiild:/build:ro"
image namecommand
in a pythonic manner.
One of the reasons for the blocker was due to the fact that the podman-py module documentation had misleading information. The documentation gave an example of "mounting a volume" that was not yet implemented in the source code, and so I was in a witch-hunt trying to figure out what was causing my code to fail even after following the documentation.
After hours of trying to figure out what was wrong, I went to podman-py Github page, and searched for volume related question on the issues page. This was when I came across this gem that informed me that volume argument had not been fully implemented, and that I needed to use mounts argument.
Later during the week, I had a call with my mentor, and we discussed about the project at length. We had a talk about the future of the libvirt project, he reviewed the work I had done during the last week, and we set deliverable for the next week.
LESSONS FROM THIS WEEK'S MEETING
We talked about event loops (i.e to repeatedly wait for an event to happen and then execute a handler that has subscribed to that particular event), and wondered if there was such an implementation in the podman-py module. This would make it easy to get real-time logs by registering an event, and calling the registered handler for that event.
Understanding SELinux labeling (I need to read more on this topic).
We also talked about various Vim plugins for being effective. While sharing my screen during review, he noticed I was struggling with commenting out large blocks of code in my Vim editor. He showed me a couple of cool plugins he uses in his day-to-day, and gave me resources to find them.
We also talked about the state of the podman-py module, and how I need to raise any bugs I find in the source code to help the community.
DELIVERABLE FOR THE FOURTH WEEK
Open an issue against podman-py to report a bug and ask couple of questions.
Refactor the git history on my fork of libvirt-ci.
Read more on argparse(a builtin CLI library in Python) to see if we can make the present implementation in lcitool more robust by making it three levels deep. If my research is fruitful, we would have something like;
lcitool container [run|build] [--env|--workdir,...] image project
where container and run|build are required sub-commands, --env|--workdir are optional arguments, and image and project are positional arguments.