Changes between Initial Version and Version 1 of WikiStart


Ignore:
Timestamp:
05/06/16 07:52:20 (8 years ago)
Author:
jaap
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart

    v1 v1  
     1[[PageOutline]]
     2
     3= CMT -- Config Management Tool =
     4{{{
     5#!NewsFlash
     6= May 3rd, 2016: Version 2.0 released =
     7PIP package:
     8* client
     9 * ftp://ftp.surfsara.nl/pub/outgoing/CMT/latest/cmt-client-2.0.4.tar.gz
     10
     11* server
     12 * ftp://ftp.surfsara.nl/pub/outgoing/CMT/latest/cmt-server-2.0.0.tar.gz
     13}}}
     14
     15CMT is a Config Management Tool originally created at SARA Computing and Networking Services, which is based in Amsterdam and known as SURFsara 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.
     16
     17The 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 SURFsara it's used in production, to generate configuration-files for services like for example `dhcpd` and `bind`.
     18
     19== Features ==
     20Some features of CMT are:
     21
     22 * Dynamically extendable data model
     23 * Server-side Django-powered easy-to-use web-interface
     24 * Client-side powerful CLI, to use CMT from shellscripts, or interactive from shell
     25 * Automagic generation of configuration files, with templates extended on Django Templates
     26 * Export stored data to, and import from JSON
     27 * Support for multiple clusters, networks, interfaces, etc...
     28 * Easy to install package for the client-side functionalities
     29 * Import the client as a Python-module
     30 * Split server- and client-functionalities as much as possible, and develop as packages apart from each other
     31 * Build an API to make it easier to integrate CMT in other software/scripts
     32
     33== Requirements ==
     34
     35=== Python/PIP packages ===
     36
     37==== CMT client ====
     38
     39 * pip
     40
     41==== CMT server ====
     42
     43In addition, the CMT server also requires:
     44
     45 * Python>=2.6
     46 * Django>=1.5
     47 * IPy>=0.75
     48 * django-extensions>=0.4
     49 * django-tagging>=0.3.1
     50 * psycopg2>=2.4.4
     51 * django-auth-ldap
     52 * south
     53
     54=== System packages ===
     55 * header files and a static library for Python
     56   * i.e.: libpython/python-libs + python-dev
     57 * header files for libpq (PostgreSQL library)
     58   * i.e.: libpq + libpq-dev
     59
     60= Installation, configuration & usage =
     61Documentation of CMT is divided into several pages.
     62
     63
     64== Client ==
     65 [Usage2/Quickstart Quickstart]:: This will give you a quick introduction on how to prepare your environment, and get started with the CMT client.
     66
     67 [Usage2/UserDocumentation 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.
     68
     69 [Usage2/TemplatingDocumentation Templating documentation]:: How to utilize CMT's templating engine to generate (config) files
     70
     71 [Data/Datastructure Datastructure documentation]:: More about CMT's datastructure. This can be handy information when writing your templates.
     72
     73
     74== Server ==
     75Documentation 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.
     76
     77 [Server2/Setup Setup Server]:: How to get the central CMT server up and running.
     78
     79
     80= Source code =
     81Currently the Subversion repository is only kept for historical purposes. All development now occurs in GIT.
     82
     83== Access repository ==
     84
     85 * [https://github.com/waxie/cmt]
     86
     87== Tarballs ==
     88Of each release a source tarball is available on:
     89
     90 * ftp://ftp.surfsara.nl/pub/outgoing/CMT
     91 * named: CMT-<version>.src.tar.bz2
     92
     93Please note: the easiest way to install is using the PIP package (as described [Usage/Quickstart here]) and the source should only be needed for development purposes
     94
     95= Development =
     96== Branching ==
     97We are working with 4 kinds of branches:
     98
     99 * master branch, called `master`.
     100 * 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.
     101 * 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 `bugfix/#]/human_readable_label]` where the hash-symbol is a number referring to the ticket of the bug-report, and the `human_readable_label` an optional label to know what it's about (without knowledge of the tickets).
     102 * 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 `feature/#[/human_readable_label]`, where the hash-symbol is a number referring to the ticket for the feature, and the `human_readable_label` an optional label to know what it's about (without knowledge of the tickets).
     103
     104== Versioning ==
     105So, we're using 2 or 3 numbers for versions, like `x.y[.z]`:
     106
     107 * `x` - major version number, only incremented when changes have been introduced that aren't compatible with earlier versions.
     108 * `y` - minor version number, incremented when changes have been done for new features that are compatible with earlier versions.
     109 * `z` - patchlevel, introduced when the first bugfix has been done on a stable branch, and incremented at each new bugfix-release.
     110
     111== Release checklist ==
     112 * [Development/ReleaseChecklist Release checklist]
     113
     114= Contact =
     115Existing bugs and feature requests for CMT can be found in our [/report/1 overview of active tickets]. If you have any issues with CMT, which aren't listed as a ticket yet, please [/newticket create a new ticket] or [mailto:cmt@sara.nl send us an email] about it.
     116
     117== Mailing lists ==
     118 * https://lists.surfsara.nl/listinfo/cmt-users -- Anouncement and discussion list -- low volume
     119 * https://lists.surfsara.nl/listinfo/cmt-dev -- Development and tickets list -- mid/high volume