Finalize podman support in conmon-rs

[haircommander]

There are a handful of features conmon-rs still lacks that podman will require. This issue will serve as a tracking issue for those remaining pieces

[ghost]

hi @haircommander @saschagrunert what are some resources (links, code files etc) one can look at to understand this issue much better?

[saschagrunert]

Hey @validsudoku. I think a good starting point would be to understand how podman uses conmon:

https://github.com/containers/podman/blob/295dd262/libpod/oci_conmon_common.go#L51-L68

in comparison to CRI-O:

https://github.com/cri-o/cri-o/blob/2fc918d4b/internal/config/conmonmgr/conmonmgr.go#L19-L23

While we have an almost full feature set for CRI-O, we now require to fulfill all requirements for Podman as well. :)

[jellllly420]

Hello! @haircommander @saschagrunert

I'm very interested in this GSoC project. I already had some experience in Rust programming and the usage of Podman and would like to learn more related to this issue.

Hope to join and finish this project.

[haircommander]

For anyone interested in participating in GSoC: registration opens on March 20 and
closes on April 4 (see https://summerofcode.withgoogle.com)

[rhatdan]

If we can get someone to mentor, this seems like a great GSoC project (Not me, I don't rust. :^)

[mgjm]

I am trying to understand the current situation. How I understand it so far:

• conmon is used directly via its binary conmon and controlled via a simple line based ctl socket
• conmon-rs is used via its own go client in pkg/client, the client internally spawns the rust conmonrs binary and controls the binary via a Cap’n Proto based api
• CRI-O can use conmon via the runtimeOCI implementation of the Runtime interface
• CRI-O can use conmon-rs via the runtimePod implementation of the Runtime interface
• Podman uses conmon via the ConmonOCIRuntime implementation of the OCIRuntime interface

If I understand it correctly so far, I see two ways for podman to use conmon-rs:

1. conmon-rs provides a wrapper binary to expose a conmon compatible binary which needs to expose the same command line flags and runtime behaviour as conmon (e.g. socket filenames and ctl protocol)
2. Podman gets extended to with another implementation of the OCIRuntime interface that uses the existing go client (pkg/client) and switches between ConmonOCIRuntime and the new implementation the same way CRI-O can switch between runtimeOCI and runtimePod

@haircommander Did I miss something? And which way did you have in mind or would you prefer?

[haircommander]

you have a good concept of it! I would definitely favor implementation 2 as it will allow us to use new features that aren't present in conmon easier. One thing of note is cri-o uses pods by default but podman doesn't. we'll need to have a new conmon-rs instance per container (unless those containers are in a pod, which can be a feature later)

[mgjm]

Nice, I also focused my proposal on variant 2.

But isn't there anyway one instance of conmon (or conmon-rs) per container necessary to manage logging, exit handling, etc.? Regardless of whether the container is running in a pod or not.

Edit: No. CRI-O starts one instance of conmon-rs per Pod and can invoke the CreateContainer call on the same instance (of the infra container). Whereas with with conmon a new instance is created per container.

For Podman: We should do the same optimisation when the pod feature of podman is utilised, but when the containers are created standalone use the the regular one conmon-rs instance per container strategy.

[haircommander]

yes, correct! I figured I'd mention because it differs from the way cri-o is able to do it because it always uses a pod

[NeerajGartia21]

Is this issue still open?
If yes, I would love to work on this issue.

[haircommander]

hey @NeerajGartia21 thanks for your interest! yeah @mgjm started the work but didn't manage to finish

[NeerajGartia21]

@haircommander Can I contribute to the unfinished task?
If yes, can you please help me getting started?

[haircommander]

I can try. Do note: it's a fairly complicated issue and it may be easier to start somewhere else. can you message me on kubernetes slack (@haircommander) or email me (pehunt at redhat.com) so I can go over what kind of help you need