1. Evaluation

1.1. Current solution

The initial request was to enable users to set-up working environment easily providing possibility of choosing:

  • compiler (and its version)
  • DataDictionary version
  • Access Layer version
  • a versions of other of libraries used by WPCD developers

As a result of discussions two steps (wpcdenv/imasenv) schema was introduced, to provide a freedom of choice and  not to make module name too complicated (like imasenv/3.24.0/intel/18.0/ual/4.1.5/wpcdenv/4.0)

  • wpcdenv (e.g. wpcdenv/intel/18.0/1.1) sets compiler, its versions and loads all DD/IMAS independent libraries (e.g. blitz, lapack, xmllib)
  • imasenv (e.g. imasenv/3.24.0/ual/4.1.5/1.1) sets IMAS for given DD version and loads all DD/IMAS dependent libraries  (e.g. ggd, amns)

1.2. Lesson learned

After one year, since it's initial design, I decided to evaluate wpcdenv/imasenv scenario. Outcome of evaluation:

  • in most cases users specify only "module load imasenv"  or "module load imasenv/<dd-ver> "
  • UAL is a "yet another library" that don't has to be set separately ("ual/<al-version>" part of schema)
  • users don't take into account *AL version* and other libs version... and use defaults 
  • users don't take into account compiler version... and use default one
  • there is a need to couple imasenv with particular wpcdenv version:
    • currently imasenv loads default wpcdenv
    • all imasenv libraries can be not compatible with other wpcdenv version as being used during compilation
    • loading manually wpcdenv by user and than imasenv can result in inconsistent environment 
  • The number of modules is growing very fast (see "module avail imasenv") - it is harder and harder to find a proper version

Thus, there is a need of simplification  of described mechanism and to provide a proper lifecycle !

2. Simplification of wpcdenv/imasenv schema

Propositions to simplify mechanism for setting working environment base on initial David C. suggestions (yes, Dave, I should follow your hints):

  • to remove "ual/<al-version>" part of imasenv module name
  • to remove "<compiler-version>" part of wpcdenv module name

  • to combine wpcdenv and imasenv within one module 

    imasenv/<dd-ver>/<compiler_vendor>/<compiler_version>/<library-set-ver>
e.g.:
imasenv/3.24.0/intel/17.0/1.0.2

Justification:

  • Proposed schema is simplification (from users point of view) of existing mechanism
  • (already mentioned) no need to handle AL differently than other libraries
  • It solves problem of coupling libraries and its dependencies used at compilation time (aka a correct wpcdenv for given imasenv)
  • The change will be transparent for the users that loads defaults calling "module load imasenv[/dd-ver]" 

3. Lifecycle

Defaults

Please note that module system allows to provide defaults on every level of module structure - a "tail" of module name can be skipped to use default versions. 

Taking imasenv as an example, following calls loads the same module :

  • module load imasenv
  • module load imasenv/3.24.0
  • module load imasenv/3.24.0/intel
  • module load imasenv/3.24.0/intel/17.0
  • module load imasenv/3.24.0/intel/17.0/1.0.2 

under assumptions:

  • 3.24.0  is a default DD version
  • intel  is default compiler
  • 17.0 is default compiler version
  • 1.0.2  is default set of libraries compiled by intel

"WPCD products"

ETS workflow is the most complex product being developed by WPCD, however WPCD activity is not limited to ETS development, so this document will refer to "WPCD products" keeping in mind that in most cases it is synonym of "ERTS workflow"

3.1. Tagged version

  • Tagged version of module, used by some tagged version(s) of  CD product(s)
  • Must be well tested  and stable 
  • This version is intended to use mainly by users , to provide them stable environment for running  CD product(s) 
  • The chosen tagged version (in most cases the latest one) is set as default  one

3.2. Release candidate (RC)

  • A candidate for a next tagged version
  • Provides a common, unified environment for developers working on next version of given CD product 
  • A RC version should be stable, however it would be changed quite often (patches, new functionality of libraries) so it may happen that RC version will have some issues
  • Once WPCD confirms that its product works fine, RC is tagged 

3.3. Alpha version

  • A candidate for a next tagged version
  • Introduced to make sure that update/change requested by developer(s) is "safe"  and will not brake environment (used by large group of developers)
  • Used by a limited group of testers (usually by person who request change plus one/two other testers)
  • Used for limited amount of time (omne, two days)
  • If tests are passed, changes are introduced to RC:
    • patches automatically
    • library updates (that may change APIs) after confirmation coming from WPCD
  • BTW: Alpha version is an equivalent of "module load imasenv/x.y.z/rc; module switch tested-lib/tested-ver" 


  • No labels