wiki:Development/Scrum

Version 69 (modified by /O=GRID-FR/C=FR/O=CNRS/OU=LAL/CN=Michel Jouvin, 12 years ago) (diff)

--

Quattor Scrum Process and Backlog

TracNav

Table of Contents

  1. Web site
  2. Documentation
  3. Build tools
  4. Pan Compiler
  5. Configuration Modules
  6. Package Deployment
  7. AII
  8. SCDB
  9. Aquilon
  10. QWG
    1. gLite
  11. Monitoring
  12. SINDES
  13. 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
2012-01 (current) 30/6/2012 wiki/Development/Scrum/Sprint-2012-01
2011-04 19/1/2012 wiki/Development/Scrum/Sprint-2011-04
2011-03 13/10/2011 wiki/Development/Scrum/Sprint-2011-03
2011-02 31/5/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. The contents should not be interpreted as a commitment to implement the listed features.

Web site

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

Build tools

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

Pan Compiler

After discussion during Quattor workshop:

  • Function to dump all defined global variables at a specific point to help debugging. Like debug() function, should do nothing if the appropriate option is not passed to the compiler. An optional argument may restrict the name of the variables dumped, with a regexp on the name (if feasible).
  • Add ability with a compiler option to get a message printed everytime a template is included with an information display wheter it has been executed or skipped because it had the unique tag and was previously executed.
    • Would be great if it worked also with structure templates...

Configuration Modules

Package Deployment

  • Replace SPMA by YUM. Even though it is a bit CERN (CDB/SWrep) specific, see ​https://twiki.cern.ch/twiki/bin/view/Main/SteveTraylen/Spma2Yum for input on problems to address and possible solutions.
    • A first action for Quattor development may be to establish a summary of this documents oriented as a list of actions, removing CERN specifics.

AII

  • Allow to use standard Anaconda disk formatting features rather than %pre script
    • 6/5: new %pre-based implementation using parted seems to fix all issues (as released in v3) and to keep more flexibility/control

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.
  • comps2pan.xsl: add an option to allow to select which kernel RPM to use to identify the kernel RPM.
    • Story: Since SL5.5, kernel-xen is used as the default kernel in comps.xml. As a result, comps2pan.xsl is not able to locate the kernel entry in comps.xml list and there is no kernel entry (using KERNEL_xxx variables) in the generated template.
  • Rewrite in Python rpmUpdates.pl and rpmErrata.pl to make it easier to use YUM API to identify the most recent RPM available.
    • Story: original version of these scripts where using a custom huristics to find out the most recent version of each RPM. This heuristics proved to be very fragile. YUM API (rpmUtils.miscutils) provides a function to do this more reliably but calling it from a Perl script result in a ugly result...

Aquilon

  • Provide an appliance with QWG templates preinstalled

QWG

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
  • Torque submit filter must be configured on the CE instead of the Torque server as it is executed by qsub command
  • 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)

Miscellaneous