Getting better...

Hello!

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

I started the week by refactoring the implementation of lcitool spawning a Podman API listening service. Due to the flaws in the old implementation i.e printing the pid to the terminal, and requiring the user to explicitly pass the pid to a stop call, there was a need to define something more grand that abstracts the pid away from the user.

After giving it a long thought, I decided to run a subprocess.Popen call with command, ps -ef to get the list of all current running process, then filter the standard output to get all podman related calls by passing grep "podman" to the stdout from the initial subprocess call.

After parsing the output from ls_process to get the pid, it is then sent to os.kill to end all the running podman system service process. This approach made it so that a simple .stop() call was enough to stop the listening service.

There was also a need to figure out how to use podman-py to build a container image from a Python script. So, I researched and found the build method provided by podman-py's ImagesManager mixin, a podman resource subclassed for image build(the equivalence of a podman build command).

The next thing was to figure out how to connect lcitool's ability to generate Dockerfile with the build method. I decided to pass the string provided by lcitool's command to generate a Dockerfile, lcitool dockerfile to io.StringIO to generate a buffer which is then passed to build'sfileobj argument.

I had a call with my mentor later in the week, and we decided to follow a slightly different approach to solving the two sub-task:

• Instead of implementing a lcitool command to launch and stop podman listening service, each container application will start a Podman API listening service, perform the job, and still be responsible for ending that specific service. A context manager will be used to carry out the implementation.

• Instead of using io.StringIO, it is better to dump the Dockerfile generated with lcitool in a temporary file and then pass the path to the dockerfile argument in the build method. This is consistent with the way lcitool works with Ansible.

The latter part of the week was spent trying to implement the provided solution and preparing the deliverable for the next week.

Things to do for week three:

• Implement the listening service using a context manager.
• The build process should print to the standard output - stdout.
• Run a simple script in a running container and print the output