On Fri, Jun 28, 2013 at 11:53 AM, Tim Hockin <thockin@xxxxxxxxxx> wrote: > On Fri, Jun 28, 2013 at 8:05 AM, Michal Hocko <mhocko@xxxxxxx> wrote: > > On Thu 27-06-13 22:01:38, Tejun Heo wrote: > > >> Oh, that in itself is not bad. I mean, if you're root, it's pretty > >> easy to play with and that part is fine. But combined with the > >> hierarchical nature of cgroup and file permissions, it encourages > >> people to "deligate" subdirectories to less previledged domains, > > > > OK, this really depends on what you expose to non-root users. I have > > seen use cases where admin prepares top-level which is root-only but > > it allows creating sub-groups which are under _full_ control of the > > subdomain. This worked nicely for memcg for example because hard limit, > > oom handling and other knobs are hierarchical so the subdomain cannot > > overwrite what admin has said. > > bingo > > Note that we also use cpu and io hierarchies as user accessible hierarchies. This makes delegation possible to google workloads for subset (sub-cgroups) creation and monitoring. > > And the systemd, with its history of eating projects and not caring much > > about their previous users who are not willing to jump in to the systemd > > car, doesn't sound like a good place where to place the new interface to > > me. > > +1 > > If systemd is the only upstream implementation of this single-agent > idea, we will have to invent our own, and continue to diverge rather > than converge. I think that, if we are going to pursue this model of > a single-agent, we should make a kick-ass implementation that is > flexible and scalable, and full-featured enough to not require > divergence at the lowest layer of the stack. Then build systemd on > top of that. Let systemd offer more features and policies and > "semantic" APIs. > > We will build our own semantic APIs that are, necessarily, different > from systemd. But we can all use the same low-level mechanism. > > Tim > _______________________________________________ > Containers mailing list > Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linuxfoundation.org/mailman/listinfo/containers > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
