Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add documentation on heterogeneous clusters (WIP) #448

Open
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

migueldiascosta
Copy link
Member

besides reviewing this text, can people submit PRs to my branch with site-specific examples?

Or maybe we should set up a separate page for those?

@boegel
Copy link
Member

boegel commented Sep 26, 2018

@migueldiascosta It's probably better to set up a specific page for sites to explain how they configure/use EasyBuild (see also #264, but someone will need to update & chase down people on that)

@boegel boegel added this to the 3.7.1 milestone Sep 26, 2018
@boegel boegel modified the milestones: 3.7.1, 3.8.0 Oct 19, 2018
@boegel boegel modified the milestones: 3.8.0, 3.8.1 Dec 19, 2018
each host only sees the software compiled for its own architecture (plus any software eventually compiled for ``GENERIC``)
or if it sees everything.

By mounting architecture dependent targets on the same mountpoint in every host, the configuration is then very similar to
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it only be changing the mointpoint? We thought about directories like /common-path/easybuild// where architecture is the instruction set name of gcc (nehalem, broadwell, skylake,...) to start with. On the nodes one would change the profile.d to prepend $MODULEPATH with the according modules path, hence module load would pick up the more optimized modules first and fall back to the other architectures, i.e. instruction sets for other modules. For example, MODULEPATH=/<....>/skylake/modules/all:/<....>/nehalem/modules/all.

Copy link
Member Author

@migueldiascosta migueldiascosta Feb 7, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@henkela this clearly needs to be rewritten, my goal was precisely to describe those two approaches (a node only seeing it's own arch, via mountpoints, or seeing everything but using only it's own arch, via variables).

Using variables is of course much more flexible, but in many simple cases using mountpoints may be more robust and foolproof (from the point of view of the nodes, and except for the custom mountpoint, it's the same as an homogeneous cluster)

@henkela
Copy link

henkela commented Feb 1, 2019

Documentation for heterogeneous clusters is also a matter of site policy. I think this page can only offer a certain way or maybe some ways to tackle this point. Building multiple software trees according to the different architectures in the cluster is common to several approaches. Another question that arises is how to build for those different architectures? Manually sending build jobs? Using ansible? Including even ReFrame maybe? Should there be a eb --multiple-arch where one could overwritte optflags,installdir,modulesdir,easyconfig-repo on the fly and trigger multiple build-jobs at once? Probably GC3Pie would get involved here, too?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants