On Fri, Oct 18, 2019 at 10:08 AM Michal Koutný <mkou...@suse.com> wrote: > > On Mon, Oct 14, 2019 at 02:42:03PM -0600, Tom Hromatka > <tom.hroma...@oracle.com> wrote: > > This may get long - my apologies up front :). > Thanks for your sharing your motivation and the explanations. > > > Whatever solution we come up with, these apps will be running on > > cgroup v1-only systems, cgroup v1/v2 systems, and cgroup v2-only > > systems. > That sounds quite ambitious and I find it definitely challenging. > > In my opinion, there are (at least) three views on this topic: > > 1) Where > > This specifies what controllers are involved and what is the hierarchy > built. libcg should either restrict access to systemd-"owned" > controllers or should be modified to be able to work under non-root > cgroup(s). > > The tentative plural in the last sentence is getting at another friction > surface, pre-systemd users of cgroup may rely on multiple orthogonal > hierarchies, that is hardly maskable by the abstraction layer. Such > compatibility is better broken (IMO). > > 2) Who > > Any systemd-wide classification done by libcg is just asking for > problems when systemd assumes potentially different distribution of > processes into cgroups. I.e. it should again be restricted to subtrees > or controllers. > > 3) What > > The attributes that are being tuned/information that is being read about > cgroups. This seems relatively trivial involving some > translations/mappings. > > > A bug in systemd could render a system unbootable, and thus they were > > afraid of putting a new feature in the large and complex codebase of > > systemd. > The upside is that systemd is widely deployed and has active community > so these are likely identified quickly. > OTOH, I see the benefit of libcg in environments without systemd (e.g. > some containers). > > > So this led us to pursue updating and improving libcgroup. Yes, > > there are potential conflicts with systemd, but I believe we can > > safely mitigate them. > As I drafted above, the way to avoid the conflict is to be > complementary. I wonder if you considered anything different. >
Michal, I sympathize with your position, but I feel obligated to point it out. systemd will not solve our issues. There are too many changes that need to be made to systemd, some which are contrary to its original design specifications, others which are fairly complex. While I would love for systemd to pick this up, the abstractions we are talking about absolutely do not belong to systemd. An application should not have to care about systemd to know how to setup its cgroups. The right thing is for systemd to delegate away cgroups. Beyond that, as Tom pointed out, our application lifespans are long. We need the stability, which we are trying to provide here. Dhaval _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
