Operating system¶

We officially support Ubuntu 11.10, Ubuntu 12.04 and CentOS 6. Ganeti Web Manager is also known to work on Debian 7 and CentOS 5.

More on compatibility page.

Base¶

• sudo
• git

These dependencies are required to install Ganeti Web Manager via setup.sh installation script. Follow up to installation instructions.

During installation, if python and python-virtualenv are not installed, they will be installed.

Databases¶

All database dependencies are installed automatically during setup.sh run. All you need is sudo priviledge. If you have any issues, please refer to Django database documentation.

If you, for any reason, want to install these database dependencies on your own, here’s the list:

MySQL

requires MySQL-python package installed within virtual environment, which in turn requires libmysqlclient18 on Ubuntu/Debian and mysql-libs on CentOS.

PostgreSQL

requires psycopg2 package installed within virtual environment, which in turn requires libpq5 on Ubuntu/Debian and postgresql-libs on CentOS.

If you’re using the setup.sh script these database dependencies should be installed for you. But if it runs into errors, these are the dependencies needed.

LDAP¶

LDAP dependencies can be found on the LDAP dependencies page.

VNCAuthProxy¶

VNCAuthProxy, is used to connect the VNC web frontend to a Ganeti VM’s VNC Console. This project is built on twisted and for encryption requires openssl and FFI development headers.

On CentOS, the OpenSSL package is openssl-devel and on Ubuntu/Debian its libssl-dev. The LibFFI package is libffi-devel on CentOS and libffi-dev on Ubuntu/Debian.

These packages are necessary to install VNCAuthProxy and should be installed before the setup script is run.

Installing¶

Installation is now automatic. There is now a shell script detects your operating system, installs required dependencies (even for your database of choice!), creates Python virtual environment and finally installs Ganeti Web Manager with its own dependencies.

1. Make sure that all Ganeti Web Manager‘s Requirements are met. For non-CentOS and non-Debian machines, make sure to see Other Platforms.

2. Next you need the latest release of Ganeti Web Manager which is 0.11.2. You can download that here: https://github.com/osuosl/ganeti_webmgr/archive/0.11.2.tar.gz. You can also clone the repo and checkout the latest tag as well:

   $ git clone https://github.com/osuosl/ganeti_webmgr.git
   $ git checkout $VERSION
   

Note

Replace $VERSION with the version you want to deploy, such as 0.11.2

It doesn’t actually matter where you put these, it will only be used for installation, which will eventually install the project to another location, which by default is /opt/ganeti_webmgr.

1. Once you’ve got the project, you will use our shell script to install things. First, cd to the Ganeti Web Manager project folder:

   $ cd ./ganeti_webmgr
   

   Next run ./scripts/setup.sh -h to get help and see all possible usages of our shell script. There are different options for installing to different locations, as well as installing different database dependencies.

2. Now that you’ve looked at the options, you’ll want to actuall install Ganeti Web Manager. By default, it will install to /opt/ganeti_webmgr and will not install any database dependencies. To do this install run the following:

   $ ./scripts/setup.sh
   

   If you want to install Ganeti Web Manager with mysql support, which means installing your systems mysql-client libraries, development headers, and the python mysql package run:

   $ ./scripts/setup.sh -D mysql
   

Note

You will likely need to run this as root as it requires permissions to install packages and create directories in /opt.

Warning

For CentOS 6, the EPEL repository must be installed to use python-virtualenv. If you do not want to install EPEL, manually install python-virtualenv and pass the -N flag to setup.sh.

VNC AuthProxy startup script¶

Ganeti Web Manager provides an in-browser VNC console. For more information, see VNC. In order to use the VNC console, you must run VNC AuthProxy, which comes with Ganeti Web Manager.

VNC AuthProxy can be set up to start on boot if wanted. To do so, it is necessary to set up an init script to manage the daemon. These vary by platform, so depending on what kind of system you are running Ganeti Web Manager on, there are a few choices.

$ sudo cp /path/to/gwm/source/scripts/vncauthproxy/init-centos /etc/init.d/vncauthproxy
$ sudo chkconfig --add vncauthproxy

$ sudo cp /path/to/gwm/scripts/vncauthproxy/init-ubuntu /etc/init.d/vncauthproxy
$ sudo update-rc.d vncauthproxy defaults

$ sudo service vncauthproxy start

$ sudo cp /path/to/gwm/scripts/vncauthproxy/init-systemd /lib/systemd/system/vncauthproxy.service
$ sudo systemctl enable vncauthproxy

Minimum Configuration¶

There are defaults for most settings, however, there are no defaults set for database settings. Make sure to set these or you will run into problems with the rest of the installation.

See configuration page for documentation on configuring Ganeti Web Manager.

Initializing¶

Because your Ganeti Web Manager instance lives within virtual environment, you must activate the virtual environment in order to access GWM:

$ source /opt/ganeti_webmgr/bin/activate

Now all the programs installed to that virtual environment are available for you (until you issue deactivate or close your terminal session).

We’ll be using the django-admin.py tool to run commands to administer our app from this point forward. You might be familiar with manage.py, which is essentially what django-admin.py is. However, we need to tell django-admin.py what settings to use, in order for it to work. To do this run the following command:

$ export DJANGO_SETTINGS_MODULE="ganeti_webmgr.ganeti_web.settings"

You only need to run this once each time you activate the virtual environment, or if you prefer, each time you run django-admin.py you can provided the --settings argument:

$ django-admin.py $CMD --settings "ganeti_webmgr.ganeti_web.settings"

$ django-admin.py bower install

$ django-admin.py refreshcache

$ django-admin.py rebuild_index

Next Steps¶

Congratulations! Ganeti Web Manager is now installed and initialized. Next, you’ll want to look into Configuring and Deployment Intro, if you are going to be setting up a production instance.

Otherwise, if you just want to play around with Ganeti Web Manager, or are developing, take a look at the Development Server.

Creating configuration files¶

To get started configuring Ganeti Web Manager with YAML, copy the config.yml.dist to config.yml in the directory where you want your settings:

$ cp /path/to/gwm/ganeti_webmgr/ganeti_web/settings/config.yml.dist /opt/ganeti_webmgr/config/config.yml

Alternatively, to configure Ganeti Web Manager with the standard Django settings.py, copy settings.py.dist to settings.py in the same directory it is in:

$ cp /path/to/gwm/ganeti_webmgr/ganeti_web/settings/settings.py.dist \
    /path/to/gwm/ganeti_webmgr/ganeti_web/settings/settings.py

LDAP configuration¶

To configure Ganeti Web Manager to use LDAP, see the LDAP documentation.

Databases¶

Ganeti Web Manager supports PostgreSQL, MySQL, Oracle, and SQLite databases. The type of database and other configuration options must be defined in either settings.py or config.yml. These settings are not set by default like most other settings in Ganeti Web Manager. Be sure to actually configure your database settings.

Configuring SQLite in config.yml:

DATABASES:
    default:
        ENGINE: django.db.backends.sqlite3
        NAME: /opt/ganeti_webmgr/ganeti.db
        USER:      # Not used with sqlite3.
        PASSWORD:  # Not used with sqlite3.
        HOST:      # Set to empty string for localhost.
                         # Not used with sqlite3.
        PORT:      # Set to empty string for default.
                         #Not used with sqlite3.

Configuring SQLite in settings.py:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': '/opt/ganeti_webmgr/ganeti.db',
        'USER': '',      # Not used with sqlite3.
        'PASSWORD': '',  # Not used with sqlite3.
        'HOST': '',      # Set to empty string for localhost.
                         # Not used with sqlite3.
        'PORT': '',      # Set to empty string for default.
                         #Not used with sqlite3.
    }
}

For PostgreSQL, Oracle, and MySQL, replace .sqlite in the engine field with .postgresql_psycopg2, .oracle, or .mysql respectively:

# config.yml
DATABASES:
    default:
        ENGINE: django.db.backends.mysql
        NAME: database_name
        USER: database_user
        PASSWORD: database_password
        HOST: db.example.com
        PORT: # leave blank for default port

Secret Keys¶

By default Ganeti Web Manager creates a SECRET_KEY and a WEB_MGR_API_KEY for you the first time you run a command using django-admin.py, and puts this key into a file located at /opt/ganeti_webmgr/.secrets/SECRET_KEY.txt. This is to make initial setup easier, and less hassle for you. This key is used for protection against CSRF attacks as well as encrypting your Ganeti cluster password in the database. Once set, you should avoid changing this if possible.

If you want to have better control of this setting you can set the SECRET_KEY setting in config.yml like so:

SECRET_KEY: ANW61553mYBKJft6pYPLf1JbTeHKLutU

Please do not use this value, but instead generate something random yourself. You do not want to share this, or make it publicly accessible. This can be used to avoid protections Ganeti Web Manager has implemented for you.

If you are using the SSH Keys feature to add keys to VMs with Ganeti Web Manager, you will also need to set the WEB_MGR_API_KEY setting in config.yml or keep the value created for you in /opt/ganeti_webmgr/.secrets/WEB_MGR_API_KEY.txt. This is the same value you will use when running the sshkeys.py or sshkeys.sh scripts. Similarly, it should be something impossible to guess, much like the SECRET_KEY setting:

WEB_MGR_API_KEY: 3SqmsCnNiuDY9lAVIh3Tx3RIJfql6sIc

Again, do not use the value above. If anyone gains access to this key, and you are using the sshkeys feature, it will allow them to add arbitrary ssh keys to your Virtual Machines.

Time zone and locale¶

Ganeti Web Manager supports time zones, translations and localizations for currency, time, etc. To find the correct time zone for your locale, visit the List of time zones. For language codes, see List of language codes. Not every language is supported by Ganeti Web Manager.

Date and datetime format follows the Django date format. For instance, d/m/Y will result in dates formatted with two-digit days, months, and four- digit years.

A standard configuration might look something like this:

TIME_ZONE: America/Los_Angeles
DATE_FORMAT: d/m/Y
DATETIME_FORMAT: "d/m/Y H:i"

LANGUAGE_CODE: "en-US"

# Enable i18n (translations) and l10n (locales, currency, times).
USE_I18N: True

# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale
USE_L10N: True

Registration and e-mails¶

To set up Ganeti Web Manager to send registration emails, you’ll need access to an SMTP server. You can configure the SMTP host, port, and email address:

EMAIL_HOST: localhost
EMAIL_PORT: 25
DEFAULT_FROM_EMAIL: noreply@example.org

For more complicated email setups, refer to the Django email documentation.

Allowing open registration means that users can create their own new accounts in Ganeti Web Manager. The users will then have the number of days set in ACCOUNT_ACTIVATION_DAYS to activate their account:

ALLOW_OPEN_REGISTRATION: True
ACCOUNT_ACTIVATION_DAYS: 7

More details can be found in the Open Registration documentation.

Site root and static files¶

The site root, static root, and static url must also be set when configuring Ganeti Web Manager.

The SITE_ROOT is the subdirectory on the website: http://example.com/<SITE_ROOT>. The current default is empty.

The STATIC_ROOT is the directory on the filesystem that Ganeti Web Manager‘s static files will be placed when you run django-admin.py collectstatic. The current default is /opt/ganeti_webmgr/collected_static.

STATIC_URL is the full url where Ganeti Web Manager will look when trying to obtain static files. The default for this is currently /static which means it will try looking at the same domain it is hosted on. For example if your hostname is www.yourwebsite.com it will look for them at www.yourwebsite.com/static.

A standard configuration, putting Ganeti Web Manager at the root of the domain, might look like this:

SITE_ROOT: /web_admin
STATIC_ROOT: /opt/ganeti_webmgr/collected_static
STATIC_URL: www.yourwebsite.com/static

Haystack Search Settings¶

Haystack is Ganeti Web Manager‘s way of performing search indexing. It currently has one setting which you need to worry about.

HAYSTACK_WHOOSH_PATH is the path to a location on the filesystem which Ganeti Web Manager will store the search index files. This location needs to be readable and writable by whatever user is running Ganeti Web Manager. Example users might be the apache or nginx user, or whatever user you’ve set the Ganeti Web Manager process to run as.

The default path for this setting is /opt/ganeti_webmgr/whoosh_index.

An example of this setting might be:

HAYSTACK_WHOOSH_PATH: /opt/ganeti_webmgr/whoosh_index

More details can be found in the search documentation.

Sentry¶

Ganeti Web Manager can log server errors to Sentry, an online exception tracker. To enable tracking, copy the raven.py.dist settings file to raven.py and set the dsn value. If you are using hosted Sentry, you can get the dsn value by logging into your Sentry account and copying it directly from their documentation.

Other settings¶

ITEMS_PER_PAGE is a setting allowing you to globally limit or extend the number of items on a page listing things. This this currently defaults to 15 items per page, so your pages will have up to 15 VMs, clusters and node’s listed on a single page. You might adjust this to a lower value if you find that loading a large number on a single page slows things down.

ITEMS_PER_PAGE: 20

Set VNC_PROXY to the hostname:port pair of your VNCAuthProxy server. The VNC AuthProxy does not need to run on the same server as Ganeti Web Manager.

VNC_PROXY: "localhost:8888"

LAZY_CACHE_REFRESH (milliseconds) is the fallback cache timer that is checked when the object is instantiated. It defaults to 600000ms, or ten minutes.

LAZY_CACHE_REFRESH: 600000

RAPI_CONNECT_TIMEOUT is how long Ganeti Web Manager will wait in seconds before timing out when requesting data from the ganeti cluster.

RAPI_CONNECT_TIMEOUT: 10

Sample configuration¶

An annotated sample YAML configuration file is shown below:

# config.yml

# Django settings for ganeti_webmgr project.

##### Database Configuration #####
DATABASES:
    default:
        ENGINE: django.db.backends.sqlite3
                    # django.db.backends.sqlite3
                    # django.db.backends.postgresql
                    # django.db.backends.mysql
                    # django.db.backends.oracle
                    # django.db.backends.postgresql_psycopg2

        # Or path to database file if using sqlite3.
        NAME: /opt/ganeti_webmgr/ganeti.db
        USER:      # Not used with sqlite3.
        PASSWORD:  # Not used with sqlite3.
        HOST:      # Not used with sqlite3.
        PORT:      # Set to empty string for default.
                         #Not used with sqlite3.
##### End Database Configuration #####

# Site name and domain referenced by some modules to provide links back to
#  the site.
SITE_NAME: Ganeti Web Manager
SITE_DOMAIN: "localhost:8000"

# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
TIME_ZONE: America/Los_Angeles
DATE_FORMAT: d/m/Y
DATETIME_FORMAT: "d/m/Y H:i"

# Language code for this installation. All choices can be found here:
# http://www.i18nguy.com/unicode/language-identifiers.html
LANGUAGE_CODE: "en_US"
##### End Locale Configuration #####

# Enable i18n (translations) and l10n (locales, currency, times).
# You really have no good reason to disable these unless you are only
# going to be using GWM in English.
USE_I18N: True

# If you set this to False, Django will not format dates, numbers and
# calendars according to the current locale
USE_L10N: True

# prefix used for the site.  ie. http://myhost.com/<SITE_ROOT>
# for the django standalone server this should be
# for apache this is the url the site is mapped to, probably /tracker
SITE_ROOT: ""

# Absolute path to the directory that holds media.
# Example: /home/media/media.lawrence.com/
STATIC_ROOT: /opt/ganeti_webmgr/collected_static

# URL that handles the media served from STATIC_ROOT.
# XXX contrary to django docs, do not use a trailing slash.  It makes urls
# using this url easier to read.  ie.  {{STATIC_URL}}/images/foo.png
STATIC_URL: /static

##### Registration Settings #####
ACCOUNT_ACTIVATION_DAYS: 7

# Email settings for registration
EMAIL_HOST: localhost
EMAIL_PORT: 25
DEFAULT_FROM_EMAIL: noreply@example.org

# Whether users should be able to create their own accounts.
# False if accounts can only be created by admins.
ALLOW_OPEN_REGISTRATION: True
##### End Registration Settings #####

####### Haystack Search Index settings #######
HAYSTACK_WHOOSH_PATH: /opt/ganeti_webmgr/whoosh_index
####### End Haystack Search Index settings #######


# GWM Specifics

# The maximum number of items on a single list page
ITEMS_PER_PAGE: 15

# Ganeti Cached Cluster Objects Timeouts
#    LAZY_CACHE_REFRESH (milliseconds) is the fallback cache timer that is
#    checked when the object is instantiated. It defaults to 600000ms, or ten
#    minutes.
LAZY_CACHE_REFRESH: 600000

# VNC Proxy. This will use a proxy to create local ports that are forwarded to
# the virtual machines.  It allows you to control access to the VNC servers.
#
# Expected values:
#   String syntax: HOST:CONTROL_PORT, for example: localhost:8888. If
#   localhost is used then the proxy will only be accessible to clients and
#   browsers on localhost. Production servers should use a publicly accessible
#   hostname or IP
#
# Firewall Rules:
#   Control Port: 8888, must be open between Ganeti Web Manager and Proxy
#   Internal Ports: 12000+ must be open between the Proxy and Ganeti Nodes
#   External Ports: default is 7000-8000, must be open between Proxy and Client
#   Flash Policy Server: 843, must open between Proxy and Clients
VNC_PROXY: "localhost:8888"

# This is how long gwm will wait before timing out when requesting data from the
# ganeti cluster.
RAPI_CONNECT_TIMEOUT: 10

Synchronizing Clusters¶

Ganeti Web Manager stores some information about clusters in its database. Cluster and virtual machine information will refresh automatically, but the list of virtual machines must be synchronized manually. This can be done by via the orphans view

1. Main Menu -> Orphans

Clusters are synchronized when the orphans view is visited.

Adding Virtual Machines¶

To add a virtual machine, select “Create VM” in the toolbar. Only fields with multiple options will be selectable. For example, if you are unable to change the cluster to which a VM gets added, it means that there is only one valid option and cluster is a mandatory field.

• If the user creating the VM has permissions to do so, the owner will be that user. If the user does not have create permissions but is a member of a group that can create VMs, ownership defaults to that group.
• Cluster can be chosen from those that the the user creating the VM has access to.
• The Hypervisor will generally be dictated by the cluster that you choose.
• The instance name must be a fully qualified domain name (FQDN). (e.g. hostname.example.org)
• If you uncheck “Start up after creation”, you can start the VM manually on its virtual machine detail page. (click Virtual Machines in the sidebar, then the VM’s name)
• DNS name check: if checked, sends the name you selected for the VM to the resolver (e.g. in DNS or /etc/hosts, depending on your setup). Since the name check is used to compute the IP address this also enables/disables IP checks (e.g. if the IP is pingable). Uncheck if using dynamic DNS.
• Disk Template chooses a layout template from these options:
  • plain - Disk devices will be logical volumes (e.g. LVM)
  • drbd - Disk devices will be DRBD (version8.x) on top of LVM volumes
    • If drbd is selected, a primary and secondary node will need to be chosen unless automatic allocation has been selection. DRBD will allow the virtual machine to use live migration and failover in case one of the nodes goes offline.
  • file - Disk devices will be regular files (e.g. qcow2)
  • diskless - This creates a virtual machine with no disks. Its useful for testing only (or other special cases).
• Operating system to install on the virtual machine. Your choices are limited to the images configured on the cluster.

General Parameters:

• Virtual CPUs will be deducted from owner’s quota. If the owner field appears blank and is not selectable, the default owner has been chosen.
• Memory is the amount of RAM to give this VM. If no units are given, megabytes is assumed.
• Disk size is the amount of owner’s disk quota to allot this VM. If no units are given, megabytes is assumed.
• Disk type determines the way the disks are presented to the virtual machine. Options may vary based on cluster’s hypervisor settings.
• More information about NIC Mode, NIC Link, and NIC Type can be found here

Hypervisor parameters:

TODO finish this part

Orphaned Virtual Machines¶

Permission Tags are parsed by virtual machine objects, but sometimes virtual machines will have no tags. To quickly identify virtual machines with no admin users, use the orphans view

1. Main Menu -> Orphans

Visiting the orphans view will force a synchronization of all clusters and display VirtualMachines that do not have any permissions assigned. You only need to grant permissions directly on virtual machines if you are granting access to non-admin users.

Development Server¶

Make sure you’ve already checked out Initializing.

If you are just testing Ganeti Web Manager out, run:

$ django-admin.py runserver --insecure

Then open a web browser, and navigate to http://localhost:8000.

If you want this to be accessable from a machine other than where you ran that command, then run the following:

$ django-admin.py runserver 0.0.0.0:8000 --insecure

Overview¶

Before beginning deploying Ganeti Web Manager using Apache, read the following Django article on deploying Django with apache and mod_wsgi.

If you haven’t already, make sure you’ve set up Static Files.

To get Ganeti Web Manager installed there are a few steps.

• Install Apache
• Configure/install mod_wsgi and other Apache modules
• Create the Ganeti Web Manager VirtualHost

<VirtualHost *:80>

    ServerName gwm.example.org

    WSGIDaemonProcess ganeti_webmgr processes=4 threads=1 python-path=/opt/ganeti_webmgr/lib/python2.6/site-packages
    WSGIProcessGroup ganeti_webmgr
    WSGIScriptAlias / /opt/ganeti_webmgr/lib/python2.6/site-packages/ganeti_webmgr/ganeti_web/wsgi.py

    Alias /static/ /opt/ganeti_webmgr/collected_static/

    <Directory /opt/ganeti_webmgr/collected_static>
        Require all granted
    </Directory>

    <Directory /opt/ganeti_webmgr>
        <Files wsgi.py>
            Require all granted
        </Files>
    </Directory>

</VirtualHost>

<VirtualHost *:80>

    ServerName gwm.example.org

    WSGIDaemonProcess ganeti_webmgr processes=4 threads=1 python-path=/opt/ganeti_webmgr/lib/python2.6/site-packages
    WSGIProcessGroup ganeti_webmgr
    WSGIScriptAlias / /opt/ganeti_webmgr/lib/python2.6/site-packages/ganeti_webmgr/ganeti_web/wsgi.py

    Alias /static/ /opt/ganeti_webmgr/collected_static/

    <Directory /opt/ganeti_webmgr/collected_static>
        Order deny,allow
        Allow from all
    </Directory>

    <Directory /opt/ganeti_webmgr>
        <Files wsgi.py>
            Order allow,deny
            Allow from all
        </Files>
    </Directory>

</VirtualHost>

uWSGI¶

Before you begin, it is adviced you read over the following uWSGI article on setting up Django with uWSGI and Nginx

If you haven’t already, make sure you’ve set up Static Files.

$ source /opt/ganeti_webmgr/bin/activate
$ pip install uwsgi

upstream gwm {
    # server unix:///path/to/gwm_uwsgi.sock; # for a file socket
    server 127.0.0.1:8001;
}

server {
    listen      80;
    server_name gwm.example.org;

    location /static {
        alias /opt/ganeti_webmgr/collected_static;

    }

    location / {
        uwsgi_pass  gwm;
        include     uwsgi_params;
    }
}

# gwm_uwsgi.ini
[uwsgi]

# GWM's wsgi file
module          = ganeti_webmgr.ganeti_web.wsgi
# the virtualenv (full path)
home            = /opt/ganeti_webmgr

# Configure based on needs
master          = true
processes       = 2
socket          = 127.0.0.1:8001
vacuum          = true

$ uwsgi --ini /path/to/gwm_uwsgi.ini

Adding users to objects.¶

1. navigate to Group, Cluster, or VirtualMachine detail page
2. click Add New User
3. select user or group
4. select permissions
5. save

Updating permissions¶

1. navigate to Group, Cluster, or VirtualMachine detail page
2. click Users tab
3. click permissions column
4. select permissions and save

Deleting permissions¶

1. navigate to Group, Cluster, or VirtualMachine detail page
2. click Users tab
3. click the delete icon

Deleting a user will remove all permissions, and other properties associated with the user such as cluster quotas.

Group Permissions¶

• admin - Grants the ability to see the member list, and edit permissions

Permission Tags¶

Permissions for virtual machines are also registered as tags on the virtual machine object. This allows the permissions to be viewed and set via the command line tool. Tags will be parsed when creating virtual machines, and will be updated when the object is refreshed (#387). When permissions are granted tags will be set on the virtual machine (#393).

Tags use the pattern: GANETI_WEB_MANAGER:<permission>:[G|U]:<user_id>

• GANETI_WEB_MANAGER:admin:U:2 - admin permission for User with id 2
• GANETI_WEB_MANAGER:admin:G:4 - admin permission for Group with id 4
• GANETI_WEB_MANAGER:start:U:2 - start permission for User with id 2

VNC AuthProxy¶

VNC AuthProxy is required for the console tab to function. VNC servers do not speak websockets and our proxy allows your ganeti cluster to sit behind a firewall, VPN, or NAT.

VNC AuthProxy has a control channel that is used to request port forwarding to a specific VNC machine. It will respond with a local port and temporary password that must be used within a short period. This allows a secure connection with the VNC AuthProxy, without compromising the vnc password, and without leaving the port open to anyone with a port scanner.

Configuring VNC AuthProxy¶

Set the host and port that the proxy uses in config.yml with the VNC_PROXY setting.

Syntax is HOST:CONTROL_PORT, for example: "localhost:8888".

If the host is localhost then the proxy will only be accessible to clients and browsers on the same machine as the proxy. Production servers should use a public hostname or IP.

# located in your settings file
VNC_PROXY = 'localhost:8888'

To set up encryption, find where VNC AuthProxy‘s working directory. This may depend on how you have set it set up to automatically start; for instance, with runit, it automatically sets the working directory to /etc/sv/vncauthproxy.

You then should put your HTTPS certificate file in /path/to/working/dir/keys/vncap.crt and your HTTPS private key in /path/to/working/dir/keys/vncap.key. VNC AuthProxy should then automatically accept encrypted connections.

$ sudo service vncauthproxy status

$ twistd --pidfile=/tmp/proxy.pid -n vncap

sudo twistd --pidfile=/tmp/policy.pid -n flashpolicy

Debugging Help¶

/usr/bin/twistd: Unknown command: flashpolicy

source venv/bin/activate

export set PYTHONPATH=.

Configuring User SSH Keys¶

SSH Keys script¶

Ganeti Web Manager provides a script that will automatically generate an authorized_keys files

$ python util/sshkeys.py [-c CLUSTER [-i INSTANCE]] WEB_MGR_API_KEY URL

• WEB_MGR_API_KEY is the value set in config.yml settings file
• URL is a URL pointing to the GWM server
• CLUSTER is the identifier of a cluster
• INSTANCE is the hostname of an instance

The GWM server URL has some flexibility in how it may be specified; HTTP and HTTPS are supported, as well as custom port numbers. The following are all valid URLs:

• http://example.com/
• https://example.com/
• http://example.com:8080/

CLUSTER and INSTANCE are optional. Including them will narrow the list of users to either a Cluster or a VirtualMachine.

SSH Keys Ganeti hook¶

If you want your VMs to automatically copy the ssh keys from GWM, then you can use the included ssh keys ganeti hook found in util/hooks/sshkeys.sh. Copy that file onto every node in your cluster in the hooks directory for the instance definition you’re using (i.e. ganeti-debootstrap). Copy and set the variables in util/hooks/sshkeys.conf into the variant config and/or the instance definition config file. Make sure that the hook is executable and all the variables are set include changing the API Key.

Dependencies¶

In order to use python-ldap a couple of system level packages need to be installed first.

For a Debian based systems:

• libldap2-dev
• libsasl2-dev

For a Red Hat based systems:

• openldap-devel

Deploying¶

To deploy Ganeti Web Manager with LDAP

1. Copy ldap_settings.py.dist to ldap_settings.py.

   $ cd ganeti_webmgr/ganeti_web/settings
   $ cp ldap_settings.py.dist ldap_settings.py
   

2. Change ldap_settings.py to fit your LDAP configuration.

   $ vi ldap_settings.py
   

   Note

   ldap_settings.py.dist has been thoroughly commented so that external documentation shouldn’t be needed. If you have specific questions about options or want an overview of the package, please consult the django-auth-ldap documentation.

3. Install the LDAP-specific requirements.

$ pip install -r requirements/ldap.txt # in root of repository

Disabling¶

If you would like to later disable LDAP support, all that is required is to remove your ldap_settings file:

$ cd ganeti_webmgr/ganeti_web/settings
$ rm ldap_settings.py

Ganeti RAPI users and passwords¶

Before you can start using Ganeti Web Manager you will need to create a user and password on the Ganeti cluster.

echo -n 'jack:Ganeti Remote API:abc123' | openssl md5

# Hashed password for jack
jack {HA1}54c12257ee9be413f2f3182435514aae write

In Read-Only mode, you CAN:¶

• Assign ownership of VMs to GWM users from the Orphans page
• Delete VMs from your Ganeti Webmanager database from the Missing VMs page
• Import nodes to your database or delete nodes from it
• Assign permissions to users on the cluster or VM (note that although you can assign VM create permission to a user or group, they cannot actually create a VM in read-only mode)
• Edit the cluster, so that you can go back and add username/password credentials and gain full privileges on it later.
• Delete the record of the cluster from your database (Note: This does not affect the actual cluster)
• Record a default quotas for Virtual CPUs, Disk Space, and Memory
• Change the cluster’s slug (the name of the cluster as it appears in the url: <hostname>/cluster/<slug>/<vm>)

In Read-Only mode, you can NOT:¶

• Redistribute the cluster’s configuration
• Start, stop, or reinstall a VM
• Migrate or change disks
• Access a VM’s console
• Create a new VM on the cluster

Closing Registration¶

In some contexts, users should not be able to create their own accounts. To implement this, simply change the ALLOW_OPEN_REGISTRATION setting in your config.yml file to False:

# Whether users should be able to create their own accounts.
# False if accounts can only be created by admins.
ALLOW_OPEN_REGISTRATION = False

Result of closed registration¶

The “Not a member?” link is hidden from users on the login page. If they navigate to the <SITE_ROOT>/accounts/register page, they will see this message instead of the account creation form:

Why are things cached?¶

Ganeti is a bottleneck when accessing data. In tests, over 97% of time taken to render a normal page in Ganeti Web Manager is spent waiting for Ganeti to respond to queries. Thus, Ganeti Web Manager caches some of Ganeti’s data.

Manual Updates¶

Sometimes it is necessary to refresh objects manually. To do this, navigate to the detail page for the cluster of the object that needs to be refreshed, and click the “Refresh” button. This will refresh the cluster and all of its objects.

Cached Cluster Objects¶

Some database-bound objects cache Ganeti data automatically. The functionality for this caching is encapsulated in the CachedClusterObject class. Any models which inherit from this class will gain this functionality.

values = VirtualMachine.objects.get(id=id)
vm = VirtualMachine()
for k, v in values.items():
    setattr(vm, k, v)

RAPI Cache¶

RAPI clients are cached in memory, and a hash of cluster information is stored in order to locate them quickly. The entire scheme is no longer necessary since RAPI clients are no longer expensive to allocate, and will be removed soon.

Features¶

1. Nodes are represented as circles, which can host a number of primary instances, and mirror data for instances hosted on other secondary nodes.
2. Any node can play the role of both a primary node or a secondary node.
3. When you click on a node, all the instances running on that node are shown.
4. Further, when you click on an instance an edge in the graph connecting 2 nodes is highlighted.
5. The edge points to the secondary node for that particular instance originating at the primary node.
6. Edge thickness between the nodes gives and idea of the total number of failover possibilities existing between two nodes.
7. All the ‘running’ instances are shown in green and all the *_DOWN instances are shown in red. Instances “red” in color are not “running” and might require a failover.
8. Additional instance information is shown in the bottom right corner and is fetched on demand on clicking on an instance.
9. Zoom In - Zoom Out using mouse scroll in any region by placing mouse-pointer there first.
10. Long-click & hold the graph at any point and pan it in any direction to shift the whole graph object or Pan by using arrow keys, or use the previous mouse method: longclick-hold-move
11. Select any node ans press the character “s” to see all the secondary instances for a given node.
12. Press the character “c” at any time to clear (actually hide) all the visible instances.
13. Press the character ‘r’ to reset the whole graph orientation as in the beginning.
14. Most of this important information is available easily pressing character the ‘h’ ie. help.

Visualizing a cluster via GWM¶

1. Navigate to Cluster detail page
2. Click the Visualize button with an ‘eye’ on it.
3. ganetiviz - opens up and renders the appropriate cluster.

History¶

In the initial stages of development I wrote a blog post on Ganetiviz. It might be a little outdated now, but will help understand the ganetiviz evolution.

The ganetiviz-cytoscape project was initially created as a front end component for ganetiviz which was then ported to devganetiviz - a django application that can be run outside GWM and ships with some mock data to get started contributing to GWM in seconds.

Improving ganetiviz¶

Since ganetiviz is a part of GWM; improving ganetiviz actually means improving GWM. Developing for GWM can sometimes be tedious for front-end contributors who do not want to concern themselves with running a live or virtual ganeti cluster with GWM every time for development purposes.

Ganetiviz has a sister project that makes it possible for anyone to start contributing easily.

1. Front-End code contribution: For any front end contribution you must refer to devganetiviz, a separate django project that comes with batteries included (fixture data, etc), so you do not need to run any physical or virtual server to add front-end features to ganetiviz.
2. For any contribution that changes JSON data avaiable to the front end component. For changing the data returned by GWM to ganetiviz, it is important to run GWM the standard way along with a Virtual or real cluster.

0.11 and later¶

Since 0.11, Ganeti Web Manager uses special setup script for installing and upgrading.

By using this script (and due to other major changes in Ganeti Web Manager architecture), you now have to use different management script. It gets installed into Ganeti Web Manager‘s virtual environment as django-admin.py. Once you’ve activated your virtual environment, it will be in your path.

In order to upgrade your database run:

$ django-admin.py migrate --delete-ghost-migrations --settings "ganeti_webmgr.ganeti_web.settings"

Updated settings¶

Description¶

When submitting an issue, the description should generally include the following:

• Exactly what the submitter did to encounter the situation
• What the submitter expected to happen
• What actually happened

Depending on the issue, knowing details about the operating system or web browser being used may be helpful.

In addition to these points, bug reports should also include any relevant information with regard to attempted fixes or workarounds as well as any other effects the bug may have on the software. Any patches which resolve or work around bugs are also appreciated, if only to help developers understand the scope of the bug.

Trackers¶

There are several “trackers” or categories of issues that can be filed.

Status¶

Status reflects where a ticket stands in the filing process.

New

This issue is new and we haven’t begun work on it, possibly haven’t even decided whether we will work on it.

In Progress

We are working on this issue.

Won’t Fix

This is a legitimate issue, but we’ve decided that it is not something we can or will work on

Duplicate

This issue is actually a duplicate of an exisiting issue

Blocked

We can’t work on this issue until another issue is resolved

Feedback

We’ve worked on this issue, or made some comments on it, and assigned it to someone for their feedback.

Resolved

We’ve completed work on this issue.

Upstream

This is actually an issue with some package or library we depend on.

Closed

We are done with this issue.

Rejected

We don’t think this is a legitimate issue, and reject it entirely

Can’t Reproduce

We believe you, but we can’t reproduce the behavior this issue refers to, so we can’t do anything with it

Priorities¶

How important it is for us to get this issue fixed.

• Low
• Normal
• High
• Urgent
• Blocker

Categories¶

Categories simply describe the general area or topic of an issue, categories may change with time depending on the project’s needs.

Difficulty¶

An estimation of how hard a bug, feature, or enhancement will be and how long it may take.

• Easy
• Medium
• Hard

Issue Triage¶

When an issue is reported on Github, the core team will triage the issue, assigning it to a release version, rejecting it, or sending it back for more information. This process may take place as part of planning for a new version release, or ad hoc in order to address an important bug in the current release.

Workflow¶

The following workflow should be followed when contributing code.

git checkout -b feature/12345

refs: #12345

Short (50 chars or less) summary of changes

refs: #12345

More detailed explanatory text, if necessary.  Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body.  The blank
line separating the summary from the body is critical (unless you omit
the body entirely); some git tools can get confused if you run the
two together.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded by a
single space, with blank lines in between, but conventions vary
here

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   hello.py
#

Github and Pull Requests¶

If work is done on GitHub or on an external repository rather than the OSL Gitolite instance, the work will be submitted to the core via a Github pull request.

Pull requests will be subject to the same review process outlined above, and should correspond to an issue in the OSL issue tracker. If no such issue exists, it must be created before accepting the pull request. When the pull request is approved, a new branch will be created following the normal naming conventions, and the work pulled into this branch. From this point, the work follows the same workflow as above.

If the original developer does not have or is not willing to create an account on the OSL tracker, and the issue needs to be assigned back for additional work, such assignment may be communicated via email, an issue on the Github issue tracker for the developers’ clone. If the developer is not willing to participate in this process, a core developer may be assigned to adopt the work, and the issue will be assigned to that developer for further work.

Final Release Tasks¶

Creating a final release consists of the following tasks.

1. All issues for the release version should be resolved and closed

2. Build and upload Python wheels for all requirements (see building wheels).

   Don’t forget to build the psycopg2 and MySQL-python wheels!

3. Bump version in docs/source/conf.py, scripts/setup.sh, and in

   ganeti_webmgr/constants.py

4. Create a release tag for this version, e.g. 0.11.2
5. Create a tar file for this release and upload it to Github’s Releases.
6. Create a Python package from the tag
7. Announce the new release to the mailing list and IRC channels

Issue Tracking¶

The bug tracker for Ganeti Web Manager is on Github, and all bugs and feature requests for Ganeti Web Manager should be tracked there. Please create an issue for any code, documentation or translation you wish to contribute.

Please see Issues for details on how to create informative issues.

Dev Environment¶

Writing and testing code is made much easier by the right tools and a development environment that mirrors a production environment. To begin working with Ganeti Web Manager code, you will need Git, Python 2.6+, and Python VirtualEnv. We also recommend VirtualBox and Vagrant, a scripting front-end to VirtualBox to set up a virtual cluster to test your code with.

source /path/to/gwm/venv/bin/activate

pip install packagename

pip freeze

Installation¶

To install the GWM application for development work, please see Developer Installation.

Ganeti Web Manager ships with support for Vagrant. This allows developers to modify and test their code in the same environment and reduce the amount of configuration necessary. See Vagrant for details on setting up the virtual machine.

In addition, use of Ganeti Web Manager requires a Ganeti Cluster. For instructions on setting up a test cluster with Vagrant, see Vagrant Test Cluster.

Alternatively, Ganeti Web Manager now comes with a Dockerfile. This allows developers to use Docker to quickly run their code without needing to deal with setup and virtual machines. For now, the included Docker setup does not set up a Ganeti Cluster, for this, Vagrant is still needed.

To use Docker, simply build the included Dockerfile:

$ docker build -t="osuosl/ganeti_webmgr:dev" .

Then, just create a Docker container from the image:

$ docker run -it -p 8000:8000 osuosl/ganeti_webmgr:dev

Ganeti Web Manager can now be accessed on http://localhost:8000. To change the port that it runs on, the first number in the above command can be changed to the port of choice.

Some developers may prefer to mount their copy of the application as a volume when they run the app. This removes the need to rebuild the Docker image each time the code is changed, and can be done as follows:

$ docker run -v /path/to/code/:/opt/ganeti_webmgr -it -p 8000:8000 osuosl/whats_fresh:dev

Repository Layout¶

We loosely follow Git-flow for managing repository. Read about the branching model and why you may wish to use it too.

master

Releases only, this is the main public branch.

release/<version>

A release branch, the current release branch is tagged and merged into master.

develop

Mostly stable development branch. Small changes only. It is acceptable that this branch have bugs, but should remain mostly stable.

feature/<issue number>

New features, these will be merged into develop when complete.

bug/<issue number>

Bug fixes.

enhancement/<issue number>

Enhancements to existing features.

See Issues for more information on issue types.

When working on new code, be sure to create a new branch from the appropriate place:

• develop - if this is a new feature
• release/<version> - if this is a bug fix on an existing release

Code Standards¶

Testing¶

Ideally, tests should be written for all code that is submitted to the project. We recommend writing a test for any new feature before writing the code.

For bugs in features that have existing tests, be sure to run the existing tests on your code before submitting. In some cases a test will need to be updated or modified to test a bug fix, this should be done before writing code to fix the bug.

Tests can be submitted for features separate from the feature code itself, and feature requests that are submitted along with tests will be much more likely to be implemented.

See Running Tests for more information on writing unit tests for Ganeti Web Manager.

See Selenium test specs for some ideas on using the Selenium web testing framework to test GWM.

Adding features¶

When adding a feature to GWM, please remember to include:

{% trans "this text will be displayed in the correct language" %}

{% blocktrans %}
    Here is a some text that will be displayed
    in the correct language but would not
    fit well in a single line
{% endblocktrans %}

Fixing Bugs¶

When bugs are fixed, the issue should be updated with a clear description of the nature of the bug, the nature of the fix, and any additional notes that will help future developers understand the fix.

Before working on a bug fix, determine if the faulty code is covered by a unit test. If so, and the test did not reveal the flaw, update the test appropriately. If no test exists, it should be written if possible. The test should be submitted along with the fixed code.

Writing Documentation¶

Documentation exists as RestructuredText files within the GWM repository, and as in-line comments in the source code itself.

pip install -r requirements/docs.txt
cd docs
make html

Submitting Code¶

Please read OSL Development Process for details on how we triage, review and merge contributed code.

Bower is used to manage javascript dependencies that have previously been stored within GWM as minimized files. For more information on django-bower, check out their docs.

To update or add Javascript dependencies, add them to base.py and run manage.py bower install. This will install the new or updated dependencies to ganeti_webmgr/bower_components. Include the added dependencies with the pull request.

git commit
git format-patch HEAD^

git format-patch origin/master

Submitting Documentation¶

Documentation is just as much a part of the project as code, and as such you can contribute documentation just as outlined above for code. See Writing Documentation for details on the documentation tree.

If you are not comfortable with git, patches or pull requests, you may submit documentation via a text file sent to the mailing list or attached to an issue. We recommend creating an issue, as this helps us keep track of contributions, but the mailing list is an excellent place to solicit feedback on your work.

Submitting Translations¶

Translations should be submitted via patches, a pull request, or by attaching a .po file to an issue. We recommend cloning the git repository and using django-admin.py makemessages to find all the available strings for translation. If you find strings in the UI that are not available for translation, patches to fix this condition are much appreciated. As with all contributions, we recommend creating a new issue on our issue tracker for your work.

For details on how to write translation strings and how to make use of them, please see Django’s i18n page

Requirements¶

• Python >= 2.6
• your compiler of choice
• python-dev for compilation of some of Ganeti Web Manager dependencies
• virtualenvwrapper (really recommended)
• or python-environment if you can’t (or don’t want to) install above wrapper
• libpq-dev (Ubuntu/Debian) or postgresql-devel (CentOS) if you want to use PostgreSQL
• libmysqlclient-dev (Ubuntu/Debian) or mysql-devel (CentOS) if you want to use MySQL

Guide¶

$ mkvirtualenv gwm

$ virtualenv ~/.virtualenvs/gwm
$ source ~/.virtualenvs/gwm/bin/activate

(gwm)$ git clone https://github.com/osuosl/ganeti_webmgr

(gwm)$ cd ganeti_webmgr
(gwm)$ git checkout develop

(gwm)$ python setup.py develop

(gwm)$ pip install mysql-python

(gwm)$ pip install psycopg2

/path/to/ganeti_webmgr/ganeti_webmgr/manage.py

What you get¶

• In /home/vagrant/ganeti_webmgr you will have your project mounted. All changes made to files in your project folder either in Vagrant, or on the host will be seen on both systems.

• You will have a Django Superuser created with the following credentials (these can be changed in the Vagrantfile):

  username: admin

  password: password

• A MySQL Database and User pre-configured for Ganeti Web Manager

All of these values can be changed by overriding the Chef attributes in the Vagrantfile.

Use¶

Using Vagrant to deploy Ganeti Web Manager is simple. You will need Vagrant version 1.5.4 or greater and two vagrant plugins, vagrant-berkshelf and vagrant-omnibus. For compatability versions, we require vagrant-berkshelf with a version greater than or equal to 2.0.

Installing Vagrant is easy, you can install it to your system by downloading the appropriate package, and running it.

To install the vagrant-berkshelf and vagrant-omnibus plugins run the following command in your terminal:

vagrant plugin install vagrant-omnibus
vagrant plugin install vagrant-berkshelf --plugin-version '>= 2.0.1'

Once you have the plugins installed you can use the following commands to start the Virtual Machine (this may take a while):

vagrant up

After it finishes and your back to your prompt, if you do not see any output after:

[default] Installing Chef 11.x.x Omnibus Package...

Then you need to run the following command to have it reprovision the VM:

vagrant provision

After provisioning, your Virtual Machine will have Ganeti Web Manager installed and running with the Apache web server. However, so that you can modify the source code, you’ll need to run the Development Server.

You can get to the VM by using the vagrant ssh command. To run Ganeti Web Manager you need to source your virtualenv and start the development server:

source /opt/ganeti_webmgr/bin/activate
cd ~/ganeti_webmgr
python ganeti_webmgr/manage.py runserver 0.0.0.0:8000

From there you can visit Ganeti Web Manager at (by default) 33.33.33.100:8000 in your web browser.

More details on vagrant can be found at http://docs.vagrantup.com/v2/

Configuration¶

Configuration of the deployment with Vagrant is done using Chef. For documentation on the available attributes for configuring the deployment visit the cookbook’s github here: https://github.com/osuosl-cookbooks/ganeti_webmgr

v0.11.0¶

Notable Changes:

• Ganeti Web Manager is now a Python package
• New installation script!
• Refactoring and new internal application structure
• Reworked configuration, with config.yml

Other:

• Added notes field to virtual machines
• The VM Wizard now has a summary page
• Updated VNCAuthProxy
• Updated documentation

v0.10.2¶

Notable Changes:

• Assigning owners to a VM has been changed slightly.
  • Must have admin/create_vm permissions to be an owner
  • Groups can be owners
  • Superusers can assign owner to anyone
  • Owner assignment dropdown is now sorted by name (finally)
• Users without perms on any clusters now get a 403 error if they try to go to the VM Creation page. Before they would get to the page but have no clusters to choose from.
• The 5th step of the VM Wizard composing of HVParams is now properly submitting the data to the RAPI
• Refresh button now refreshes data for nodes and vms instead of just the cluster from the RAPI.
• Hostnames are now stored in the database using all lowercase
• More validation on data retrieved from the RAPI
• Updated sshkeys scripts to be more redundant
• Fixed missing CSRF token on password reset page
• VM List pages should be consistent between the global VM list and the cluster VM lists

v0.10.1¶

Notable Changes:

• Cluster defaults are now used for all steps in VM Wizard. Previously NIC settings and Disk size had no defaults.
• Pinned Versions of dependencies

Other:

• Fixed bug for KVM where kernel path was required, now optional. (KVM only)
• Fixed exception when owner of a VM was a group
• During VM Creation the form now properly raises a validation error if primary node is the same as the secondary node

v0.10¶

Notable Changes:

• Ganeti 2.6 Support
• VM Wizard
• Job List - Cluster
• LDAP Support
• Manual Refresh Button
• Notice on Read-Only Clusters
• Sharedfile Disk Template Added

Other:

• Docs now ship with product
• Fabfile cleaned up and simplified

v0.9.2¶

• Pinned requirements at Django 1.4. Project not reviewed for Django 1.5 compatibility.

v0.9.1¶

• New Error list page
• Pagination links now correctly show up on the Virtual Machines page
• Migrate button disabled for non-drbd VMs on VM detail page
• VM template fields correctly set NIC and DNS defaults for new VM
• Fix network devices not copied back to new VM page, when deployment fails
• Account password reset form fixed
• Error messages on VMs clearable again

v0.9¶

Notable changes:

• Django 1.4
• Ganeti 2.5 support
• Pip 1.0+ support
• Remove PyCurl dependency
• Immediate Shutdown button
• Improved installation process and documentation
• Improved RAPI functionality

Other:

• Simplified layout infrastructure
• Fix CSRF Token errors
• Transaction middleware
• Check VM hostnames for illegal characters
• New Help Tips
• Many back-end fixes to improve standards compliance and Django best practices
• Many user interface fixes and improvements

v0.8.1¶

Bugfix release.

Bugs fixed:

• CsrfResponseMiddleware removed from settings.py.dist

v0.8¶

Notable Changes:

• VM Templates
• Multiple Disks and Nics for VM Creation
• ‘No Install’ option for VM Creation
• CDROM2 Image Path for KVM
• User auto-complete for all username fields
• Rework and stabilisation of Jobs
• User registration is now optional
• CPU info added to node list and detail pages
• Ability to replace disks for a VM on DRBD clusters

Other:

• Cached AJAX calls
• Unified json package use (django.utils.simplejson)
• Reduced name collisions with directory reorganizing
• Cache refresh migration moved to post_migrate hook
• Unified use of CSRF tokens

v0.7.2¶

• Fixed HAYSTACK_SITECONF default setting
• Updated README to include virtualenv for mod_wsgi script

v0.7.1¶

• Updated Fabric dependency: Django Object Permissions 1.4.1
• Overview: Used resources was not displaying clusters when used did not permissions

v0.7¶

Notable Changes:

• Xen Support
• Internationalization Support (only greek translations.)
• Fabric & Virtual Environment deployment.

• Improved Navigation:

  • Search
  • Contextual links added to more pages
  • Breadcrumbs available on most pages

• Object log upgraded to 0.6 includes scalability improvements

• Object permissions upgraded to 1.4

  • speed improvements
  • contextual links added to generic views
  • user/group selection widget added for permission editor.

• noVNC updated to latest head, includes better support for future revisions
• Node Evacuation now works properly
• VirtualMachine owner can now be edited

• Periodic Cache updater

  • now syncronizes Nodes
  • now runs using twistd

• Nodes can now be imported through the user interface
• Various UI fixes
• Various optimizations to views to improve load times.

v0.6.2¶

• fixing packaging issue with object log

v0.6.1¶

• updating object log to 0.5.1

v0.6¶

Notable Changes:

• Nodes are now cached in the database:
• Node detail views are now available, including some admin methods
• VirtualMachines may now be edited, renamed, and migrated.
• Errors while creating virtual machines are now handled better, and can be recovered from
• Django Object Log is now providing logs for all objects tracked by GWM
• Admins can now add ssh keys for other users
• Virtual machine detail page has had its layout updated to be more readable and add more
• fixed bugs preventing syncdb working with postgresql

v0.5¶

Notable Changes:

• Status Dashboard is now the front page for GWM

  • lists cluster status for admins.
  • lists summary of virtual machines status for users.
  • lists resource usage for the user and groups.
  • error list including job failures and ganeti errors.

• Integrated NoVNC, an HTML5 + WebSockets VNC viewer
• Super users can now view resource usage and permissions for users and groups.
• Virtual machine lists are now paginated for quicker loading
• Ram and CPU quota is now based off running virtual machines
• Improved layout
• Virtual Machines list now properly works for cluster admins

v0.4¶

Initial Release

• Caching system

• Permissions system:

  • user & group management
  • per cluster/vm permissions

• basic VM management: Create, Delete, Start, Stop, Reboot
• ssh key feed
• basic quota system
• Import tools

Next¶

1.0¶

Status Dashboard¶

Viewing virtual machines in a cluster¶

Creating a new Virtual Machine¶

Virtual Machine Console¶

Virtual Machine Detail Page¶

I added a virtual machine using the gnt-instance command-line tool, and I don’t see it in GWM!¶

Use the “Import VM” page (linked from the admin sidebar) to add those virtual machines to GWM.

How do I limit the resources available to a user?¶

Change the user’s quota on the cluster. Default quotas for virtual CPUs, disk space, and memory can be set when adding the cluster. After adding a user to the cluster, their quota will be listed in the “Users” tab of the cluster detail page. Their quota will be listed if it was set from default, or shown as an infinity sign if there is no existing quota. Click on the user’s quota to add or edit the amounts of disk space, memory, and CPUs available to that user.

What does “Autostart” do?¶

When the “Autostart” mark on a virtual machine’s detail page is a green check mark, it means that the virtual machine will be automatically started if the node reboots. Otherwise, if the mark is a red cross, the virtual machine will only start when a user manually starts it.

I get the error “Whoosh_index not writable for current user/group”¶

When running GWM through Apache, it is required that the apache user (or www-data) and group can write to the whoosh_index directory.

chown apache:apache whoosh_index/

Core Contributors¶

• Ken Lett (kennric) - kennric@osuosl.org
• Peter Krenesky (kreneskyp) - peter@osuosl.org
• Corbin Simpson (MostAwesomeDude) - simpsoco@osuosl.org
• Trevor Bramwell (bramwelt) - bramwelt@osuosl.org
• Scott White (whiteau) - whiteau@osuosl.org
• Piotr Banaszkiewicz (pbanaszkiewicz) - piotr@banaszkiewicz.org
• Lance Albertson (ramereth) - lance@osuosl.org
• Rob McGuire-Dale (robatron) - rob@osuosl.org
• Emily Dunham (edunham) - edunham@osuosl.org
• Jonah Brooks (brookjon) - brookjon@osuosl.org
• Chance Zibolski (ecnahc515) - chance@osuosl.org
• Evan Tschuy (tschuy) - tschuy@osuosl.org
• Ian Kronquist (radens) - iankronquist@osuosl.org

Google Summer of Code 2013¶

• Pranjal Mittal (pmittal) - mittal.pranjal@gmail.com
• Piotr Banaszkiewicz (pbanaszkiewicz) - piotr@banaszkiewicz.org

Google Code In 2010¶

• Jonathan Smith (jaydez) - j.jaydez@gmail.com
• Kyle Cesare (kylc) - kcesare@gmail.com
• Kapeel Sable (kapeel) - kapeelsable+p@gmail.com
• Samuel Dolean (samm) - selony24@gmail.com
• David Zderic - dzderic@gmail.com
• Crypt Wizard - cryptwizard@gmail.com
• Piotr Banaszkiewicz (pbanaszkiewicz) - piotr@banaszkiewicz.org

Other Contributors¶

• Apollon (apoikos) - apollon@noc.grnet.gr
• Faidon Liambotis (paravoid) - faidon@admin.grnet.gr
• Leonidas Poulopoulos - leopoul@noc.grnet.gr

Included Projects¶

Release Tarballs include noVNC by Joel Martin.

Search function uses Haystack by Daniel Lindsley.

Haystack search uses Whoosh by Matt Chaput.

Icons are from Silk set by Mark James.

MonkeyPatcher is used from testtools, written by Jonathan M. Lange and the testtool authors. It is seperately licensed under the MIT License.

The testtools authors are:

• Canonical Ltd
• Twisted Matrix Labs
• Jonathan Lange
• Robert Collins
• Andrew Bennetts
• Benjamin Peterson
• Jamu Kakar
• James Westby
• Martin [gz]
• Michael Hudson-Doyle
• Aaron Bentley
• Christian Kampka
• Gavin Panella
• Martin Pool

and are collectively referred to as “testtools developers”.

Internally Created Add-Ons¶

Django Object Permissions

Django Object Log

Twisted VNCAuthProxy

Versions¶

Ganeti Web Manager uses Major.Minor.Point release numbering. Major versions will incorporate major changes to the application and do not gaurantee backwards compatibility with previous major version databases. Minor versions may incorporate significant changes, but must maintain a consistent upgrade path from previous minor versions. Our Major version is currently 0, as we have not yet released version 1.0.0, the current 0.x series will become 1.0.

Our feature target for 1.0 is near complete feature parity with the ganeti RAPI, after which the 1.x series will be considered stable and no further major structural changes will be integrated. We will then begin work on the 2.0.0 development version, which will incorporate major refactoring of the codebase to separate the UI from the core and communications with the RAPI.