Hi Ken, Robert, all, On Apr 14, 2015, at 9:53 AM, Kenneth Hoste <[email protected]> wrote: > One issue is that properties are key-value, and specifying something like > --module-properties=state:testing;arch:mic:offload becomes unreadable quite > quickly.
The advantage of this approach is that possible properties are not hardwired, therefor infinitely extendible. We can iterate over multiple different ways about how to do it, however preserving this feature is very important, possibly the only one that matters from my PoV. > The approach we're currently considering is to support properties indirectly, > i.e. via options --sticky-module, --state, --arch, etc. (and/or equivalent > easyconfig parameters). IMHO, this goes against the above principle, unless I miss something. > These could imply more than simply setting a property; for example > --state=testing could imply to also install a hidden module, while specifying > --arch=mic could imply enabling a particular toolchain option to enable MIC > support (or maybe enabling a toolchain option 'mic' could imply setting the > arch:mic property). This extension mechanism can indeed be useful and can build upon orthogonality; fi. it could trigger a hint in relation to 32bit vs 64bit builds, parallel run modes etc. > If you are interested in having support for module properties in EasyBuild, > please provide some feedback by answering the following questions: > > * What kind of properties would you like to be able to add to module files > generated by EasyBuild? I’ve met this need while applying Continuous Integration (ie. cdash/ctest) against modules. Certainly this is one direction that will be served: how to mark your CI-tested modules/toolchains. > * How would you like to see properties supported? Which command line options > and/or easyconfig parameters would you expect to see added? anything that allows extensibility without having to touch the sources of EB would be reasonable > * Does a command line option like --sticky-module (and/or easyconfig > parameters 'sticky = True') make sense, i.e. which modules (generated by > EasyBuild) would you make sticky? Referring to my FOSDEM’14 presentation, I’d make sticky exactly two modulefiles: * a buildset (fi. HPCBIOS.201504020), containing a set of builds (hm... buildset concept is manual, not in EB) * a bundle (fi. PRACE.*ictce), containing the default toolchain for which a system is optimised against/with Thinking a bit more about it, I wonder if the module properties may help us to solve another itch: - when a user belongs to multiple groups, each providing its own modulenamespace, perhaps we could define priority of importance of different namespaces (if each corresponds to a modulefile of “module use” type). Just my rumbling over here, if you understand what this latter is all about, please ping me in private. best, Fotis -- echo "sysadmin know better bash than english" | sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
