containers/conmon

Rust implementation of conmon

saschagrunert opened this issue · 8 comments

saschagrunert commented

We recently discussed the possibilities of re-implementing conmon in Rust. (cc @mrunalp @haircommander)

This issue should be used to gather further pros and cons to find the right move forward.

Funny enough, I privately started porting conmon to Rust a while ago. I cleaned up the fork and have a diff available here: main...saschagrunert:rust

It's still using glib, which is something we probably would like to avoid in the future (if we decide to continue the idea).

haircommander commented

An advantage that a rust rewrite gives us is the ability to redefine what conmon does. For instance, there would be advantages in having one conmon per pod (podmon 😁), and have managers talk to that pod level conmon over some API, rather than execing for each container creation/exec. This will give us savings in long running managers that end up having ballooning rss from concurrent os.Exec() calls

From my perspective, I think we should think about this as a set of breaking changes that constitute conmon v3, rather than attempt a 1:1 re-write.

rhatdan commented

SGTM

saschagrunert commented

From my perspective, I think we should think about this as a set of breaking changes that constitute conmon v3, rather than attempt a 1:1 re-write.

I agree, do you think we should do it in 2 steps?

  1. Migrate the current functionality 1:1
  2. Introduce breaking changes

SGTM

Do we wanna create a new repository for that or have the conmon rust implementation as part of this repository? For example, containers/conmon.rs ?

haircommander commented

I think we should migrate most of the functionality, but not the structure. this is an opportunity for us to totally rework how conmon works to be easier to read and follow. I don't think we should recreate the conmon binary, but take most of the functionality and create something new (which includes breaking changes)

@mrunalp made https://github.com/containers/conmon-rs which I think can serve as a place to work on it

rhatdan commented

Go for it.

saschagrunert commented

@mrunalp made https://github.com/containers/conmon-rs which I think can serve as a place to work on it

Good, let's move issues over there and close this one for now.

tyler92 commented

there would be advantages in having one conmon per pod (podmon grin), and have managers talk to that pod level conmon over some API, rather than execing for each container creation/exec. This will give us savings in long running managers that end up having ballooning rss from concurrent os.Exec() calls

Hi! It sounds great from my point of view. Sorry, I didn't find the right place for my question - are there any plans to implement this feature in C conmon?

saschagrunert commented

there would be advantages in having one conmon per pod (podmon grin), and have managers talk to that pod level conmon over some API, rather than execing for each container creation/exec. This will give us savings in long running managers that end up having ballooning rss from concurrent os.Exec() calls

Hi! It sounds great from my point of view. Sorry, I didn't find the right place for my question - are there any plans to implement this feature in C conmon?

Hey, no such enhancements are only planned for the Rust version.