Quattor Scrum Process and Backlog

Table of Contents

1. Web site
2. Documentation
3. Build tools
4. Configuration Modules
5. SCDB
6. QWG
   1. gLite
7. Monitoring
8. SINDES
9. RHEL6/SL6 support
10. Miscellaneous

Quattor development principles are inspired by the ​Agile Manifesto. Development process is based on the ​scrum method, an ​agile software development methodology.

A key idea of the scrum method is to make small incremental steps toward implementing new features and improvements required by the users. All the missing features, desirable functionalities or wishes are registered in the (product) backlog.

Development process is organized as a succession of sprints which, for Quattor, are two month long. The work done as part of a specific sprint is a subset of the backlog and is described in a separate wiki page.

Sprint ID	Due date	Backlog URL
2011-02 (current)	15/3/2011	wiki/Development/Scrum/Sprint-2011-02
2011-01	15/3/2011	wiki/Development/Scrum/Sprint-2011-01
2010-01	03/02/2011	wiki/Development/Scrum/Sprint-201102

This page contains the Quattor backlog. It reflects the state of the backlog at the beginning of the current sprint, with all items moved to the sprint backlog removed. Each section describes the backlog for a specific part of the Quattor toolkit.

Web site

• Remove Trac request for a user certificate for anonymous access
• Fix navigation menu behaviour

Documentation

• Clarify or add missing material to answer Ronald's questions after his QWG migration experience
• Implement changes based on Andrea's review (to be monitored in monthly meetings)
• Ensure Quattor is reference on the appropriate open-source or software project portals
  • Ohloh
  • ​Krugle
  • ​Freshmeat

Build tools

• Use of new build tools for other toolkit components (probably 1 by 1)

Configuration Modules

• ncm-dpmlfc
  • New schema using nlist rather than list (key=hostname) for service host lists: this is required to simplify checks wheter an entry already exists. This change will not be backword compatible at the template level but the component may support both old and new schema.

SCDB

• Tool to check that RPMs for a gLite service, as published on ​http://glite.org, are present in a given XML profile with a version greater or equal to what is required
  • Story: RPM list published for gLite services include both gLite RPMs and other mandatory dependencies. In QWG templates they are declared in several templates. This is impossible to generate templates from official RPM lists and several services no longer have a metapackage, leading to missing RPMs in resulting QWG configuration. The idea is to have a script that will check that all the RPMs in the official list are present with a version at least equal to what is required in a node configured with QWG template (its XML profile).
• SCDB deployment script bug (Michel)
• Add ability to invoke build-tags.py directly from post-commit.py rather than through sudo, when running it under SVN account (generally apache) is acceptable.

QWG

• Rework the definition of RPM version to use using an improved default version mechanism. This involves:
  • Modified ncm-spma function pkg_repl to mark addition of a default version with a special value
  • Modified ncm-spma function pkg_resolve to resolve default version in the (final) package list
  • Update current rpms.tpl to do pkg_repl with default version and to define an initial list of package default version
  • Update update/errata RPM list to update the default version list
  • Remove reexecution of update/errata templates in many places...

gLite

• CE Capacity Share published based on Torque/MAUI (LRMS?) fairshare configuration
  • Current support is a static declaration not connected with the actual configuration of the CE
• YAIM support as an alternative to QWG service configuration using the same variables (yaim.tpl in replacement of service.tpl)
• WN profile cloning: allow to use several different reference nodes in the same cluster
  • Story: sometimes it is necessary to use different reference nodes for different subset of a clusters, to accomodate different OS version/arch for example.

Monitoring

SINDES

• Integration in Quattor server configuration (RAL)

RHEL6/SL6 support

Miscellaneous

• Migrate panc, ccm+ncm-ncd+ncm-cdispd and AII to Git (distinct) repositories