Virtual server monitor:TODO

From Revolution Linux OpenSource projects

Jump to: navigation, search

This is a list of features to add to vsmon that might (or might not) be added in a future version. This TODO list applies to the development version of vsmon

Contents

[edit]

Done for next release

  • Simpler main interface listing a summary of all hosts
  • Search field for hosts and vservers
  • Possibility to enter an owner for earch virtual server
  • Show disk usage.
  • Hide some informations in collapsable sections to make the page easier to read.
[edit]

TODO in the future

[edit]

Packaging

  • Have well made Debian packages
  • Make official Mandriva packages?
    • Change RPMs category
[edit]

In general

  • Daemonize vsmon, so start-stop-daemon can be used properly.
    • Make the chcontext call from within the program?
  • Support for Xen/VMware?
  • Identify OS of hosts and virtual servers
  • Integrate with collectd
[edit]

Web interface

  • Make it possible to specify the port of the hosts to monitor.
  • Unify the backend pyro objects with django's database objects (put the database object as an attribute of the backend's object)
  • Make it possible to sort the vserver list by name, memory used, number of process, etc.
  • Have an icon that shows if the vserver is running or not.
[edit]

Backend

  • Make the host/port the backend binds to configurable
  • Read info from /proc/virtual using context 0? (For now, the backend runs in context 1, which does not have access to /proc/virtual).
    • Get load of each virtual server (need to be in context 0...).
  • Implement the Pyro codeValidator?
  • Understand why monitoring server's uptime on Debian is inexact.
[edit]

Nagios plugin

  • Make an independant plugin (independant of vsmon...) to ease deployments
  • The percentage displayed is not the same as in the df command. This is because of the reserved blocks for root in the ext3 filesystem. See what to do about that.
[edit]

Backend remodeling

The idea is to generalize the backend so it uses a plugin mecanism. Plugins would be :

  • generic host infos
  • Linux-Vservers
  • other virtualization technology, like VMware or Xen
  • anything else, considering the new generic backend would be a read-only solution.

The plugins would be all in Python. Configuration on the backend would activate/deactivate plugins. The frontend would need to specify the list of plugins it would like information from. The response object would contain a member per plugin, i.e., if host_info and vservers where enabled, the response object woud look like : 

response.host_info
response.vservers
Retrieved from "/Virtual_server_monitor:TODO"
Personal tools