[WIP] Initial implementation of resource-control via systemd and dbus

[nimrodshn]

What this does?

Adds easy API for interacting with systemd via dbus (namely creating units), using this we can apply resource control via systemd.

Please note: I try to align with runc's approach in this line of work to walk in the steps of giants.

TODO:

• Implement the "controllers" abstraction for each resource supported by systemd properties. (Traits and respective implementation).
• Finish implementing start_transient_unit_for_container which eventually applies the properties to the newly created unit associated with the container (the last for loop doesn't compile in the current vesion 😢 ). The bindings generated to the dbus interfaces are used using the following command: > dbus-codegen-rust -s -g -m None -d org.freedesktop.systemd1 -p /org/freedesktop/systemd1 (See https://github.com/diwic/dbus-rs)

Related issue: #24

cc: @utam0k @Furisto

[utam0k]

@nimrodshn Is there anything I can do to help?

[nimrodshn]

@utam0k Sorry I was busy with other projects 😢 I will try and get some work on this soon..

[utam0k]

@nimrodshn I understand. You can do it at your own pace. I was a little worried because you've been contributing to youki quite a bit.

[nimrodshn]

@utam0k Sorry I was busy with life 😅 . I will try to advance this asap. Dont worry - I'm here 😸

I was a little worried because you've been contributing to youki quite a bit.

@Furisto suggested I make the resource control part modular (similar to how we provide Controller impls for each controller type, e.g. memory, io etc.) in the v1/v2 cgroups managers. How do you envision that API work here? Should we pass a list of controllers to start_transient_unit_for_container in addition to LinuxResources? As These are provided statically in each cgroups manager (For example here.) - I think that might be a simple solution that way this dbus client could be used both for v1 and v2 systemd cgroup managers.

[Furisto]

@nimrodshn My idea was that the dbus client should not know anything about resources or controllers. The responsibility of the dbus client is to communicate with systemd and nothing else. The responsibility of the controllers is to translate the resource restrictions described in the spec to systemd properties.
That means they get passed in a Resource and return back properties. We collect these properties from the controllers (and maybe additional ones that are created by the cgroup manager directly like for pids) and hand them over do the dbus client. Should systemd support further resources in the future we can just add another controller without having to touch the surrounding code. It also means that v1 and v2 controllers can generate different properties, but the dbus client does not need to have any special handling for this as it just receives a list of properties.

You do not need to implement it exactly like this though, if you think you have a better idea, go for it.

[Furisto]

@nimrodshn Can I support you in any way?

[nimrodshn]

@Furisto No I'm good thanks! I just came back to this 😄

[utam0k]

@nimrodshn Hi! Can I ask you to write out the remaining work?

[nimrodshn]

@utam0k Wrote the work to be done in the PRs description ⬆️

[utam0k]

@nimrodshn Thanks! Let me know if you are busy or need any help. This isn't going to be included in the first release of youki, so taking it slow is fine. Please don't feel pressured. We need your help, I'll be waiting for you to come back ;)

[nimrodshn]

Thanks @utam0k currently finding it hard to work on open source 😿 as I'm in between jobs so taking it one step at a time 😸

[utam0k]

Thanks @utam0k currently finding it hard to work on open source as I'm in between jobs so taking it one step at a time

Of course, there are times like that. No problem. I'm waiting for this PR to be open, so let me know when you have more time. If you'll have plans to resume trying this issue, please let me know.

[utam0k]

@Furisto @yihuaf
This PR has been pretty much left out of the main codes, so leaving it any longer would be a huge burden on @nimrodshn. I hope he will take on another challenge when he has more time to contribute to youki.
Would you be interested in taking over this PR? I'd like to remain his commits and take over.

[yihuaf]

@Furisto seems to have more context on this than I do. If @Furisto is busy, I can certainly help to finish this. Just let me know :)

[Furisto]

@utam0k @yihuaf Sure, I can take over.

[utam0k]

@Furisto Thank you for accepting it. I have assigned you this issue. Can I leave it to you to decide how to proceed?

[Furisto]

@utam0k Sure

[utam0k]

We'll continue here. @nimrodshn Thanks a lot.
#451