On Tue, Aug 23, 2011 at 11:35:55AM -0700, Dhaval Giani wrote: > On Tue, Aug 23, 2011 at 11:26 AM, Vivek Goyal <vgo...@redhat.com> wrote: > > On Tue, Aug 23, 2011 at 11:21:28AM -0700, Dhaval Giani wrote: > >> On Tue, Aug 23, 2011 at 10:34 AM, Vivek Goyal <vgo...@redhat.com> wrote: > >> > On Tue, Aug 23, 2011 at 10:26:12AM -0700, Dhaval Giani wrote: > >> >> > Ok. But we still have that problem of conflict between systemd and > >> >> > cgconfig cgroups. > >> >> > > >> >> > What if a user wants following hiearchy. > >> >> > > >> >> > root > >> >> > / \ > >> >> > xyz systemd > >> >> > > >> >> > systemd will create its groups in top hierachy and cgconfig does not > >> >> > have > >> >> > any way to control them. > >> >> > > >> >> > >> >> why should cgconfig care about it? > >> > > >> > Because one of the current jobs of cgconfig is allowing creating a > >> > abitrary > >> > complex cgroup hierarchy in a persistent manner. > >> > > >> > Are you saying that above is not a valid configuration using cgconfig? > >> > > >> > >> It is, but cgconfig doesn't necessarily have to work with that model. > >> We just care about the persistent groups which we have. cgconfig is a > >> lot more flexible than we give it credit for ;-). One of the bigger > >> uses I see for it is that of namespaces, applications can define how > >> they want their cgroup to be setup and assign tasks as they care. > > > > How would applications assign tasks to cgroups? That means application > > is aware of the cgroup. If application is aware of cgroup, then he > > does not have to use cgconfig for that and applications can keep > > all the configuraitons with them and create groups dynamically, like > > systemd and libvirt do. > > > > This leads to my other question in another mail that in general who > > uses cgconfig and how it is useful without having any capability to > > enforce what is launched in what group. > > > > Umm. No, not really. So that would mean, these applications would need > to parse through different files, figure out how cgroups are mounted, > and then have the ability to create their own groups inside the root > level and then create groups internally.
- These applications only parse through the files they already maintain and understand. cgroup just becomes another property like many other property of the object being managed (virtual machines in case of libvirt and services in case of systemd). So no new config files, just an few additional attributes. - These applications create child cgroup in cgroup where these are launched. So they don't have to worry about reset of the cgroup configuration. They probably just need a small api to create a child group in current cgroup and i think libcgroup should be able to provide that. - In case of cgconfig, these applications are completely in dark. They just don't know what does it mean. Are you expecting an application to parse cgconfig and figure out where to launch children? How is that possible in current framework. > Its a lot of complication > that we get rid of. The fact that systemd and libvirt did not find the > interfaces useful means our design is wrong and we need to fix it. I > am all for breaking ABI compatibility with a new version and doing > things right. We don't have enough users to justify carrying around > all the mistakes of the past. That's fine. As we are going back to drawing board, I am just trying to raise some concerns. Thanks Vivek ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
