Difference between revisions of "Procedure Infrastructure upgrade"
Andrea.manzi (Talk | contribs) |
Andrea.manzi (Talk | contribs) (→Containers upgrade) |
||
| Line 20: | Line 20: | ||
The infrastructure is equipped with 2 types of containers : | The infrastructure is equipped with 2 types of containers : | ||
| − | * gHN : | + | * gHN : customisation of a Globus WS core 4.0.4 container |
| − | * SmartGears : a set of extension to Tomcat to enable registration and activation of | + | * SmartGears : a set of extension to Tomcat to enable registration and activation on the infra |
| + | |||
| + | The main documentation regarding the containers is the gCube Admin guide: | ||
| + | |||
| + | * gHN : https://gcore.wiki.gcube-system.org/gCube/index.php/Administrator_Guide | ||
| + | * Smartgears: https://gcube.wiki.gcube-system.org/gcube/index.php/SmartGears_gHN_Installation | ||
| + | |||
| + | ==== gHN ==== | ||
| + | |||
| + | The gHN unfortunately implements an old flat classloader schema, which means that common and application libs are all shared and stored in the same folder. When a new version of the gHN is available we should understand which changes have been applied. The typical changes are: | ||
| + | |||
| + | 1) a new version of the libraries part of the gHN | ||
| + | 2) a new version of the web services part of the gHN | ||
| + | 3) a change on the configuration of the GHN | ||
| + | |||
| + | At this level of maturity the gHN upgrades difficult introduce not backward compatibilities, which should make life easier.. | ||
| + | |||
| + | In order to upgrade an existing installation we have been always using 2 type os scripts: | ||
| + | |||
| + | * ''upgrade script'': The script downloads the new version of the gHN from Maven, removes the old libraries and copies the new ones by keeping the existing Web Services installed | ||
| + | * ''clean script'': The script runs a reinstallation of the gHN by keeping only the WebService state. | ||
| + | |||
| + | The latest versions of the scripts are available on svn at: | ||
| + | |||
| + | https://svn.research-infrastructures.eu/d4science/gcube/trunk/ghn-distribution/upgrade-scripts/ | ||
| + | |||
| + | The rule behind the execution of the upgrade or the clean script in a running installation is : | ||
| + | |||
| + | * if the gHN is empty ( the gHN is not running any other web service other than the basic gCube ones ( Deployer, GHN Manager, ResultSet) | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | ====SmartGears ==== | ||
Revision as of 14:49, 8 April 2014
Preparation of the upgrade plan
This page http://wiki.i-marine.eu/index.php/Resources_Upgrade#gCube_Upgrade contains the list of gCube upgrades perfomed in iMarine so far.
the page containing the information for QA updates is the one for the scope Ecosystem VOVirtual Organization;, for instance:
http://wiki.i-marine.eu/index.php/Upgrade_Plan_300_Ecosystem
When dealing with the preparation of a deployment plan we should deal with different categories of components:
- Containers
- gHN
- Smartgears
- gCube Services
- WebApplications
- Portal and Portlets
Containers upgrade
The infrastructure is equipped with 2 types of containers :
- gHN : customisation of a Globus WS core 4.0.4 container
- SmartGears : a set of extension to Tomcat to enable registration and activation on the infra
The main documentation regarding the containers is the gCube Admin guide:
- gHN : https://gcore.wiki.gcube-system.org/gCube/index.php/Administrator_Guide
- Smartgears: https://gcube.wiki.gcube-system.org/gcube/index.php/SmartGears_gHN_Installation
gHN
The gHN unfortunately implements an old flat classloader schema, which means that common and application libs are all shared and stored in the same folder. When a new version of the gHN is available we should understand which changes have been applied. The typical changes are:
1) a new version of the libraries part of the gHN 2) a new version of the web services part of the gHN 3) a change on the configuration of the GHNgCube Hosting Node.
At this level of maturity the gHN upgrades difficult introduce not backward compatibilities, which should make life easier..
In order to upgrade an existing installation we have been always using 2 type os scripts:
- upgrade script: The script downloads the new version of the gHN from Maven, removes the old libraries and copies the new ones by keeping the existing Web Services installed
- clean script: The script runs a reinstallation of the gHN by keeping only the WebService state.
The latest versions of the scripts are available on svn at:
https://svn.research-infrastructures.eu/d4science/gcube/trunk/ghn-distribution/upgrade-scripts/
The rule behind the execution of the upgrade or the clean script in a running installation is :
- if the gHN is empty ( the gHN is not running any other web service other than the basic gCube ones ( Deployer, GHNgCube Hosting Node. Manager, ResultSet)
