Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Finalize podman support in conmon-rs #1127

Open
haircommander opened this issue Feb 22, 2023 · 13 comments
Open

Finalize podman support in conmon-rs #1127

haircommander opened this issue Feb 22, 2023 · 13 comments

Comments

@haircommander
Copy link
Collaborator

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
Copy link

ghost commented Feb 28, 2023

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

@saschagrunert
Copy link
Member

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
Copy link

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
Copy link
Collaborator Author

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

@rhatdan
Copy link
Member

rhatdan commented Mar 2, 2023

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

@mgjm
Copy link
Contributor

mgjm commented Mar 31, 2023

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
Copy link
Collaborator Author

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
Copy link
Contributor

mgjm commented Apr 25, 2023

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
Copy link
Collaborator Author

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
Copy link

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

@haircommander
Copy link
Collaborator Author

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

@NeerajGartia21
Copy link

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

@haircommander
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants