wiki:WikiStart_old

Version 28 (modified by ramonb, 11 years ago) (diff)

--

CMT -- Cluster Management Tool

CMT is a Cluster Management Tool originally created at SARA Computing and Networking Services, which is based in Amsterdam and known as SARA nowadays. It once started as a single script, went through some reincarnations, and now it consists of a Django-powered backend on the server-side, and a CLI for the client-side.

The main reason behind CMT's existence is that we needed a tool that's capable of generating configuration-files for certain software running on our clusters. CMT has a database, where we store information about our hardware, which is used to (let CMT) generate configuration-files, based on templates. At SARA it's used in production, to generate configuration-files for services like for example dhcpd and bind.

Features

Some features of CMT are:

  • Dynamically extendable data model
  • Server-side Django-powered easy-to-use web-interface
  • Client-side powerful CLI, to use CMT from shellscripts, or interactive from shell
  • Automagic generation of configuration files, with templates extended on Django Templates
  • Export stored data to, and import from JSON
  • Support for multiple clusters, networks, interfaces, etc...
  • Easy to install package for the client-side functionalities

Wished features for future releases are:

  • Import the client as a Python-module
  • Split server- and client-functionalities as much as possible, and develop as packages apart from each other
  • Build an API to make it easier to integrate CMT in other software/scripts

Requirements

  • Django>=1.2, <1.3
  • IPy==0.75
  • django-extensions==0.4
  • django-tagging==0.3.1
  • psycopg2==2.4.4

Besides these Python-packages, the following software should be installed on your system:

  • Python>=2.6
  • header files and a static library for Python
  • header files for libpq (PostgreSQL library)

Setup & Usage

Documentation of CMT is divided into several pages.

Server

Documentation about the central CMT server can be found here. This is meant for administrators of the central CMT server only. Users of CMT should skip this, and continue at the client documentation in the next subsection.

Setup Server
How to get the central CMT server up and running.

Client

Quickstart
This will give you a quick introduction on how to prepare your environment, and get started with the CMT client.
User documentation
Further details about how to use CMT as a user. This describes how to manage the information you store in CMT, and how to do this by using the interfaces it has.
Templating documentation
How to utilize CMT's templating engine to generate (config) files
Datastructure documentation
More about CMT's datastructure. This can be handy information when writing your templates.

Source code

Currently the Subversion repository is only kept for historical purposes. All development now occurs in GIT.

Access repository

At this moment it's not (yet) possible to clone the GIT repository anonymously / externally.

You can however, browse the source code here:

Development

Branching

We are working with 4 kinds of branches:

  • master branch, called master.
  • stable branches, called stable/<version> (where versions consist of 2 digits like 1.0, 1.1, 2.0, etc.). Those stable branches are tagged whenever bugfixes are done for a bugfix-release. Those bugfix-releases (for example as for stable/1.0) are tagged as stable/<version>.<patchlevel>, where the patchlevel is an integer that increments for each (couple of) merged bugfix(es). Stable branches are branched from master, and merged back to master whenever it's tagged as a new bugfix-release.
  • bugfix branches, in which we have a branch for each bugfix to patch, branched from a stable branch. These branches can be locally. The branches are called <stable-branch>/bugfix/#> where the hash-symbol is a number referring to the ticket of the bug-report.
  • feature branches, in which we have a branch for each new feature, branched from master. These branches can be locally, however can be public for collaboration-purposes as well. As a naming-convention we'll call these branches master/feature/#, where the hash-symbol is a number referring to the ticket for the feature.

Versioning

So, we're using 2 or 3 numbers for versions, like x.y[.z]:

  • x - major version number, only incremented when changes have been introduced that aren't compatible with earlier versions.
  • y - minor version number, incremented when changes have been done for new features that are compatible with earlier versions.
  • z - patchlevel, introduced when the first bugfix has been done on a stable branch, and incremented at each new bugfix-release.

Release checklist

Contact

Existing bugs and feature requests for CMT can be found in our overview of active tickets. If you have any issues with CMT, which aren't listed as a ticket yet, please create a new ticket or send us an email about it.

Mailing lists