Under Construction

• ETICS service stability
• Problems are seen with the stability of the ETICS service: build nodes being not in good shape (AFS not properly working), unavailability of build results. ETICS stability has to be ensured.
• Add "create source tarballs" as product of the build
  • Provide a switch which means "create source tarballs wherever possible, but do not fail otherwise"
• Produce signed rpms (the ETICS signature proves that the rpms have not been altered since the build, it is not a validation/certification from ETICS).
• Partition of privileges on the basis of platform to allow porters to make progress on non-core platforms without affecting the main build
• Source patch management
• Easy builds with alternative compilers and python versions, eg SL4/gcc4.1/python2.5
• Support for multiple build artifacts from one source object
• Subsystems as tags
  • • easily build multiple subsystems against the project
    • easily build multiple components against the project

Chroot environments

• Support build support in chroot environments (virtual machines) so the dependencies are installed as they have been configured to expect at runtime (ie at --configure=prefix location). This is also an issue with external dependencies. E.g. mysql-devel has a sybmolic link to mysql. Both of them are registered in ETICS, but using them as dependencies for building a component does not work. ETICS install both externals into different directories and thus the symbolic link is broken.

Triggering rebuilds

• utility to increase age across a subsystem to force a rebuild
• utility to manage the rebuild of dependent components when a library changes

Other

• apt/yum support on the ETICS permanent repository
• support for files under /etc in packager
• support for multiple packages from one component/spec , eg to produce mylib and mylib-devel

Locking

• SA3 supports 'non-resolving' locking as giving the best balance between reproducibility and usability.

Deployment Tests

Installation of the middleware without any configuration.

Immediate Deployment Test after a build by a developer

For any set of artifacts produced by a developer (typically in the volatile repository) this test should check if well defined versions (production, pps or cert) of the affected gLite services can be updated with these artifacts. The following points have to be considered

• It should be easy for a developer to launch the deployment test for selected artefacts (project, subsystem or component) of a given build.
• The user has to be able to specify against which gLite service and which version (production, pps, certification) the test should be run.
• ETICS must be able to produce repositories (yum, apt, ...) containing artefacts.
• ETICS must be able to install (as root) production, pps as well as cert gLite services.

Deployment tests for patches

For a given patch, based on the "Affected Metapackages" we want to install these node types and upgrade them with the patch. For this ETICS would have to be able to dynamically run sub-tests.

Regular Deployment Test for a complete gLite build

For a complete build of gLite a deployment of the various gLite services should be done.

• Deployment of a service from scratch as well as updating of existing services should be tested.
• For deployment from scratch ETICS has to know about the software that has to be installed for a particular service. This is on the level of individual rpms. Lists of rpms for revery service are being maintained by the release team. A way has to be found how ETICS can get/maintain this information.
• It has to be decided on which build of gLite (HEAD etc.) to do the deployment tests.

System Tests

Simple regression tests

By "simple" we mean tests that can be done on one gLite node. The node is configured to be part of an existing grid infrastructure (e.g. the certification testbed). In this category we do not consider tests that require the installation and configuration of several gLite services. The following points have to be considered:

• ETICS must be able to install, update and configure gLite services with versions as defined by the release management (production, pre-production, certification).
• A useful application would be regression testing for patches: ETICS should be able to parse a Savannah patch, configure and install the affected node types and run the corresponding regression tests (provided by SA3).

ETICS schedule

ETICS internal planning is publicised at https://etics.web.cern.ch/etics/collaboration/WP1/project.asp

-- OliverKeeble - 23 Feb 2009