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-01 (current)	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

Configuration Modules

• upgrade components to use perl-CAF to help with RHEL6 support: Luis to produce a list of affected components first.
• ncm-network full rewrite
• ncm-dpmlfc
  • Rewrite without dabase-related functions and use ncm-mysql to configure the database (changes required in DPM/LFC templates)
  • 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).

QWG

• Produce (and maintain!) a QWG release without gLite templates: #230
• 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 configuration: allow different list of VOs on different CEs sharing the same gridmapdir
• YAIM support as an alternative to QWG service configuration using the same variables (yaim.tpl in replacement of service.tpl)

Monitoring

SINDES

• Integration in Quattor server configuration (RAL)

RHEL6/SL6 support

Miscellaneous

• Check how Git repositories can be configured on SF, migration from SVN, how many repositories by project...