Procedure Infrastructure upgrade

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 any Servlet based container to enable registration and activation on the infra of webapps ( at the moment only tomcat is installed)

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:

• a new version of the libraries part of the gHN
• a new version of the web services part of the gHN
• 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 of 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 gCube Services installed. He modifies also the existing configuration if needed. In case one of the existing base gCube services ( Deployer, GHNgCube Hosting Node. Manager, ResultSet) needs to be updated it takes care also of undeploy the old version and deploy the new one
• clean script: The script runs a reinstallation of the gHN by keeping only the gCube service state. it can be needed in case of changes of java version ( e.g. move from java 6 built artifacts to java 7) as well

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, it's always better to run a clean script
• if most of the libraries part of the gHN, the gCube services installed and their deps have changes better to run a clean script
• if only part of the the libraries or the conf of the gHN has changed, better to always run an upgrade script.

Of course the main difference between the 2 scripts is the result. The upgrade script does not require any other action from the site manager, while the clean script requires that the gCube services previously installed on the node have to be reinstalled.