new cg-manager gui tool for managin cgroups

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/20/2011 03:20 PM, Jason Baron wrote:
> Hi,
> 
> I've been working on a new gui tool for managing and monitoring
> cgroups, called 'cg-manager'. I'm hoping to get people interested in
> contributing to this project, as well as to add to the conversation
> about how cgroups should be configured and incorporated into
> distros.
> 
> * Intro
> 
> I've created a Fedora hosted page for the project, including a screen
> shot at:
> 
> https://fedorahosted.org/cg-manager/
> 
> To build and run, it's:
> 
> $ git clone git://git.fedorahosted.org/cg-manager.git $ make $ sudo
> ./cg-gui
> 
> I've also setup a mailing list to discuss the gui at:
> 
> https://fedorahosted.org/mailman/listinfo/cg-manager-developers
> 
> Currently, I assume the root user, but I hope to relax that
> assumption in future versions. The program is still quite rough, but
> its been fairly stable for me. Its a GTK 2.0 based application,
> written in C (to interface with libcgroup as much as possible).
> 
> * Brief summary of current functionality:
> 
> There are two top-level panes (which can be switched b/w using toggle
> buttons). The first one centers around cgroup controllers, and the
> second one is about configuring cgroup rules.
> 
> The memory and cpu share controllers are currently supported (I
> simply haven't gotten to supporting other controllers yet). One can
> add/delete cgroups, change configuration parameters, and see which
> processes are currently associated with each cgroup. There is also a
> 'usage' view, which displays graphically the real-time usage
> statistics. The cgroup configuration can then be saved into
> /etc/cgconfig.conf using the 'save' menubar button.
> 
> The rules view allows for the creation of rules, such as this process
> for this user goes into this cgroup. One can view rules by user and
> by process name. One can also save the rules configuration into
> /etc/cgrules.conf.
> 
> I've also introduced the concept of a 'logical' cgroup, which is
> incorporated into the cgroup pane and the rules pane. Basically, it
> allows you to group at most one cgroup from each hierarchy into a
> logical group. And then you can create rules that assign processes to
> that logical group.
> 
> * Future direction:
> 
> I've been working Mairin Duffy on what the UI look and feel should
> eventually look like...Right now, I have a lot of the elements from
> Mairin's mockups in my UI, but its certainly not quite as polished.
> Mock-ups can be found at:
> 
> http://mairin.wordpress.com/2011/05/13/ideas-for-a-cgroups-ui/
> 
> * Integration with Fedora/systemd:
> 
> Right now, the gui assumes that the various hierarchies are mounted
> separately, but that the cpu and cpuacct are co-mounted. Its my
> understanding that this is consistent with how systemd is doing
> things. So that's great.
> 
> Currently, the gui saves its state using cgconfig.conf, and
> cgrules.conf. It will display what libvirtd and systemd are doing,
> but will not save the state for any of the cgroups that are created
> by libvirt or systemd. So, it basically ignores these directories as
> far as persistent configuration. Thus, it should not conflict with
> what systemd or libvirtd are doing.
> 
> However, I think we need to discuss how we envision cgroup
> configuration working longer term. The current consumers out of the
> box, that I'm aware of are libvirt and systemd. Currently, these
> consumers manage cgroups as they see fit. However, since they are
> managing shared resources, I think there probably is an argument to
> be made that its useful, to have some sort of global view of things,
> to understand how resources are being allocated, and thus a global 
> way of configuring cgroups (as opposed to each new consumer doing its
> own thing).
> 
> Thus, various privaleged consumers could make 'configuration
> requests' to a common API, basically asking what's my configuration
> data. If there is already data the consumer can proceed assigning
> tasks to those cgroups. Otherwise, it can create a new request, which
> may or may not be allowed based upon the available resources on the
> system. And each consumer can handle what it wants to do in this
> case, which could potentially include tweaking the global 
> configuration.
> 
> So for example, in the case of systemd, it continues to have the
> default configuration that it currently has, but if the user has gone
> in and tweaked the global configuration, that configuration may be
> re-assigned once we're far enough along in the boot process to read
> what that configuration is.
> 
> Thanks,
> 
> -Jason
> 

Split the gui in 2.  A Priv part (DBUS auto started service) and a non
priv part.  X should not run as root.  Then use DBUS for communications
between the GUI and the server.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4nPMUACgkQrlYvE4MpobNdvgCePZ3eGB1oEXVMzoQ2k+k0W7cY
yGIAoLa2to5BFfMWh8U1Iq4LQHB/YMXT
=hs/8
-----END PGP SIGNATURE-----