| Version 13 (modified by , 17 years ago) (diff) |
|---|
How to Install QWG Templates
TracNav
Table of Contents
Note : QWG templates are intended to work both with original CVS-based CDB and the new Subversion-based SCDB. But their integration has been tested mainly with SCDB and tools described here applies mainly to SCDB. Report any problem you could encounter with original CDB.
Initial Installation
For an initial installation of QWG templates, you first need to initialize you repository with a base configuration database. If you want to use SCDB, follow instructions on how to configure your Quattor server with SCDB, in particular SCDB initialization.
Upgrading an existing repository
If you are using the recommended template layout with separate areas for standard templates in your configuration database, upgrading should be no more than replacing the previous version of the templates.
We do our best to ensure that new versions are backward compatible. This means that if you made site customization using the described method (pro_lcg2_config_site, pro_site_cluster_info...) and didn't modify standard templates, no changes should be required to use new version of the templates. When this is really required to introduce a new feature or bring more flexibility for configuring a service, it can happen that this full compatibility cannot be retained. This is normally stated in release announcement. You are always better to check...
Standard templates are made of 3 areas (see template layout) :
- OS templates : they are never modified, except for fixes. The only modifications apply to errata RPM list. These errata are not installed by default.
- Middleware templates (if using them) : they bring both changes and fixes at each release. They are intended to be backward compatible : that means the resulting configuration should be the same if you don't change your local configuration. As part of QWG releases, they deliver gLite updates : GLITE_UPDATE_VERSION allows to control deployment of gLite updates as part of QWG templates update.
- Standard templates : all modifications in this area are entirely backward compatible
There are 2 methods to upgrade QWG templates, according to the structure and constraints of your site :
- In place upgrade : in this scenario, existing templates will be upgraded and the changes will be deployed on all clusters of your site. You can control the gLite updates you deploy on a per node basis.
- Fresh installation of new middleware templates : this allows to control on a per cluster basis the deployement of new QWG templates. In this scenario, you are still doing an in-place upgrade of standard and OS templates.
In-place Upgrade
An in-place upgrade basically involves :
- Checking out the QWG template release you need, in a separate area from your configuration database.
- Synchronize your configuration database with your local copy of QWG templates.
Note : you are advised to maintain an area where you have checked out QWG templates from QWG repository (never check out the whole templates branch but only the version you need, [source:templates browse] through the repository to find it). This way updgrading to a new version is much more efficient : you can use svn update or svn switch` to download only the changed bits.
To integrate new/changed templates in your configuration database, you can use the tool documented at Development/RepUpdate?, originally developped to do the reverse synchronization (update QWG repository from a real configuration database). This tool can be used only with SCDB, as it relies on Subversion to do a non destructive update. As a benefit, it cannot damage your configuration database as every change made by this tool can be reverted with Subversion.
After importing all the changes with directory-sync (or manually), you need to commit them into your SCDB, after checking it compiles successfully and the changes in the profiles look appropriate (generally mainly some RPMS update). For this last check you can use src/utils/profiles/compare_xml script. After integrating the new templates, identify the changed templates, review the change if necessary and revert those not appropriate. You'll probably need to revert changes of all templates in directories repository (these templates are site specific but some of them are required to reside in standard directories for multiple version support).
Note : when checking for changes brought by a new version, you can temporaly define GLITE_UPDATE_VERSION to your current version. This way you should have no changed RPMs.
Fresh Installation of New Middleware Templates
In this scenario, you first have to download the new version of the templates, as in previous scenario. After, rather than sync'ing your templates with the release, you can copy the middleware templates provided by the release (e.g. grid/glite-3.0.0) in a new directory under cfg/grid in your CDB/SCDB and add them to the repository (use svn add for SCDB).
After you can select the deployment of the new release on a per cluster basis. For this, you have to edit cluster.build.properties of the cluster and update the include path, replacing references to previous release of middleware templates by reference to the new one you just added.
Controlling gLite Updates Installation
Starting with QWG templates release gLite-3.0.2-10, it is possible to control on a per node, per cluster or per site basis the deployment of a specific gLite update provided by QWG templates. This is done by defining variable GLITE_UPDATE_VERSION in a node profile, pro_site_cluster_info.tpl or pro_lcg2_config_site.tpl respectivly. The value of the variable is generally a Glite update number : in fact it needs to match a directory name under cfg/grid/glite-3.0.0/updates.
