Problems with new dependencies to lmod-ohpc when updating from 1.3.1 to 1.3.2

[dharly]

Hi,

while updating today from 1.3.1 to 1.3.2 we ran in to RPM conflicts that were not there before. The reason for that seems to be that all updated packages involving MPI now depend on lmod-ohpc.

Lmod-ohpc itself conflicts with environment modules which causes our problem in particular.

I am not sure if that is intentional or not - the dependency to lmod that is, not the conflict, that one I understand in principal - however this breaks our nice crossover setup we have going on.

I tried to "downgrade" back to the 1.3.1 versions but that was not possible since the 1.3.1 versions are not visible anymore. I then tried to screw around with the repo-update URL but that was not successful either.

How can I make sure I only update to 1.3.1 versions? And more importantly will this dependency to lmod-ohpc stick around?

Any input is appreciated. Requested information will be given promptly.

Thanks in advance.

Yours, Daniel

Setup: Cluster Manager: Bright 8.0 Operating system: CentOS 7.3

[koomie]

Hello Daniel,

The conflict was added due to issues reported by users who had environment-modules installed. In particular, openhpc packages rely on some advanced features in Lmod that are not supported by environment-modules so we explicitly called out the conflict to (hopefully) avoid confusion. The original thread on this is at:

https://groups.io/g/OpenHPC-users/topic/lmod_error_any_ideas/806056

So, I think it will likely stick around. Since Lmod can parse tcl files (in fact, that's still the mode we use in ohpc), any chance you can use it to parse module files you are getting elsewhere?

In regards to your repo question, if you really wanted to, you could update your local ohpc .repo file to point to the 1.3 Update1 repo directly directly (you'd need to edit the repo file by hand to no longer use the generic [OpenHPC-updates] repo). It would look something like the following for centos/x86:

[OpenHPC]
name=OpenHPC-1.3 - Base
baseurl=http://build.openhpc.community/OpenHPC:/1.3/CentOS_7
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-OpenHPC-1

[OpenHPC_1.3_Update1]
name=1.3.1 - Update #1 (June 2017) (CentOS_7)
type=rpm-md
baseurl=http://build.openhpc.community/OpenHPC:/1.3:/Update1/CentOS_7/
gpgcheck=1
gpgkey=http://build.openhpc.community/OpenHPC:/1.3:/Update1/CentOS_7/repodata/repomd.xml.key
enabled=1

[dharly]

Hi Karl,

appreciate your fast reply. We are running in 1.3.1 "locked mode" for now. Read the thread you gave as explanation and honestly do not think it is the job of OHPC to protect users from using their own stuff in conjunction with it. You provide an environment that works when the components are deployed as intended and may not work when used otherwise (i.e. what I am doing). However by fixing some peoples problems you may introduce problems for other people ...

Since I am the only one complaining I don't see that we will change sth. here, but it is well worth noting that I see two major factors in OHPC. The first being a complete management stack for a HPC-System and the second being/becoming a "default" for software/libraries to run on a HPC-system. The latter is interesting because for now it was completely disjoint from the first part. With such restriction however these parts get more entwined which means we need to be careful when using the softwarestack only.

Yours, Daniel

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.