Changes between Version 40 and Version 41 of WikiStart_old


Ignore:
Timestamp:
08/14/13 16:19:18 (11 years ago)
Author:
sil
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WikiStart_old

    v40 v41  
    22
    33= CMT -- Cluster Management Tool =
    4 
    54{{{
    65#!NewsFlash
     
    3534* https://oss.trac.surfsara.nl/cmt/browser/git/sara_cmt/CHANGES?rev=6a9bc76016ddd7753ee0bfed3989806dea9fd4d4
    3635}}}
     36CMT is a Cluster 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.
    3737
    38 CMT is a Cluster Management Tool originally created at SARA Computing and Networking Services, which is based in Amsterdam and known as SURFsara nowadays.
    39 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.
    40 
    41 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.
    42 CMT has a database, where we store information about our hardware, which is used to (let CMT) generate configuration-files, based on templates.
    43 At SURFsara it's used in production, to generate configuration-files for services like for example `dhcpd` and `bind`.
    44 
     38The 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`.
    4539
    4640== Features ==
     41Some features of CMT are:
    4742
    48 Some features of CMT are:
    49 * Dynamically extendable data model
    50 * Server-side Django-powered easy-to-use web-interface
    51 * Client-side powerful CLI, to use CMT from shellscripts, or interactive from shell
    52 * Automagic generation of configuration files, with templates extended on Django Templates
    53 * Export stored data to, and import from JSON
    54 * Support for multiple clusters, networks, interfaces, etc...
    55 * Easy to install package for the client-side functionalities
     43 * Dynamically extendable data model
     44 * Server-side Django-powered easy-to-use web-interface
     45 * Client-side powerful CLI, to use CMT from shellscripts, or interactive from shell
     46 * Automagic generation of configuration files, with templates extended on Django Templates
     47 * Export stored data to, and import from JSON
     48 * Support for multiple clusters, networks, interfaces, etc...
     49 * Easy to install package for the client-side functionalities
    5650
    5751Wished features for future releases are:
    58 * Import the client as a Python-module
    59 * Split server- and client-functionalities as much as possible, and develop as packages apart from each other
    60 * Build an API to make it easier to integrate CMT in other software/scripts
    6152
     53 * Import the client as a Python-module
     54 * Split server- and client-functionalities as much as possible, and develop as packages apart from each other
     55 * Build an API to make it easier to integrate CMT in other software/scripts
    6256
    6357== Requirements ==
    64 
    65 * Django>=1.2, <1.3
    66 * IPy==0.75
    67 * django-extensions==0.4
    68 * django-tagging==0.3.1
    69 * psycopg2==2.4.4
     58 * Django>=1.2, <1.3
     59 * IPy==0.75
     60 * django-extensions==0.4
     61 * django-tagging==0.3.1
     62 * psycopg2==2.4.4
    7063
    7164Besides these Python-packages, the following software should be installed on your system:
    7265
    73 * Python>=2.6
    74 * header files and a static library for Python
    75 * header files for libpq (PostgreSQL library)
    76 
    77 
     66 * Python>=2.6
     67 * header files and a static library for Python
     68 * header files for libpq (PostgreSQL library)
    7869
    7970= Installation, configuration & usage =
    80 
    8171Documentation of CMT is divided into several pages.
    8272
     73== Server ==
     74Documentation 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.
    8375
    84 == Server ==
    85 
    86 Documentation about the central CMT server can be found here.
    87 This is meant for administrators of the central CMT server only.
    88 Users of CMT should skip this, and continue at the client documentation in the next subsection.
    89 
    90  [Server/Setup Setup Server]::
    91    How to get the central CMT server up and running.
     76 [Server/Setup Setup Server]:: How to get the central CMT server up and running.
    9277
    9378== Client ==
     79 [Usage/Quickstart Quickstart]:: This will give you a quick introduction on how to prepare your environment, and get started with the CMT client.
    9480
    95  [Usage/Quickstart Quickstart]::
    96    This will give you a quick introduction on how to prepare your environment, and get started with the CMT client.
     81 [Usage/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.
    9782
    98  [Usage/UserDocumentation User documentation]::
    99    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.
     83 [Usage/TemplatingDocumentation Templating documentation]:: How to utilize CMT's templating engine to generate (config) files
    10084
    101  [Usage/TemplatingDocumentation Templating documentation]::
    102    How to utilize CMT's templating engine to generate (config) files
    103 
    104  [Data/Datastructure Datastructure documentation]::
    105    More about CMT's datastructure. This can be handy information when writing your templates.
    106 
     85 [Data/Datastructure Datastructure documentation]:: More about CMT's datastructure. This can be handy information when writing your templates.
    10786
    10887= Source code =
    109 
    11088Currently the Subversion repository is only kept for historical purposes. All development now occurs in GIT.
    11189
    11290== Access repository ==
    113 
    114 At this moment it's not (yet) possible to {{{clone}}} the GIT repository anonymously / externally.
     91At this moment it's not (yet) possible to `clone` the GIT repository anonymously / externally.
    11592
    11693You can however, browse the source code here:
     94
    11795 * [source:git/sara_cmt/]
    11896
    11997== Tarballs ==
     98Of each release a source tarball is available on:
    12099
    121 Of each release a source tarball is available on:
    122100 * ftp://ftp.surfsara.nl/pub/outgoing/CMT
    123101 * named: CMT-<version>.src.tar.bz2
     
    126104
    127105= Development =
     106== Branching ==
     107We are working with 4 kinds of branches:
    128108
    129 == Branching ==
    130 
    131 We are working with 4 kinds of branches:
    132 * master branch, called `master`.
    133 * 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.
    134 * 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.
    135 * 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.
     109 * master branch, called `master`.
     110 * 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.
     111 * 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/#>` where the hash-symbol is a number referring to the ticket of the bug-report.
     112 * 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/#`, where the hash-symbol is a number referring to the ticket for the feature.
    136113
    137114== Versioning ==
     115So, we're using 2 or 3 numbers for versions, like `x.y[.z]`:
    138116
    139 So, we're using 2 or 3 numbers for versions, like `x.y[.z]`:
    140 * `x` - major version number, only incremented when changes have been introduced that aren't compatible with earlier versions.
    141 * `y` - minor version number, incremented when changes have been done for new features that are compatible with earlier versions.
    142 * `z` - patchlevel, introduced when the first bugfix has been done on a stable branch, and incremented at each new bugfix-release.
     117 * `x` - major version number, only incremented when changes have been introduced that aren't compatible with earlier versions.
     118 * `y` - minor version number, incremented when changes have been done for new features that are compatible with earlier versions.
     119 * `z` - patchlevel, introduced when the first bugfix has been done on a stable branch, and incremented at each new bugfix-release.
    143120
    144121== Release checklist ==
    145 
    146   * [Development/ReleaseChecklist Release checklist]
     122 * [Development/ReleaseChecklist Release checklist]
    147123
    148124= Contact =
    149 
    150 Existing bugs and feature requests for CMT can be found in our [/report/1 overview of active tickets].
    151 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.
     125Existing 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.
    152126
    153127== Mailing lists ==
    154 
    155   * https://lists.surfsara.nl/listinfo/cmt-users -- Anouncement and discussion list -- low volume
    156   * https://lists.surfsara.nl/listinfo/cmt-dev -- Development and tickets list -- mid/high volume
    157  
     128 * https://lists.surfsara.nl/listinfo/cmt-users -- Anouncement and discussion list -- low volume
     129 * https://lists.surfsara.nl/listinfo/cmt-dev -- Development and tickets list -- mid/high volume