<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Several things to keep in mind...</p>
<ol>
<li>Slurm, as a product undergoing frequent, incompatible
revisions, is not well-suited for provisioning from a stable
public repository! On the other hand, it's just not that hard to
build a stable version where you can directly control the
upgrade timing.</li>
<li>If you really want a closely managed source for your Slurm
RPMs, get them from the SchedMD website.<br>
</li>
<li>"You could have solicited advice..." -- while this is
certainly true, for many of us in the open source world, the
standard is "release something quickly, and then improve it,
based in part on feedback, over time."<br>
</li>
<li>Slurm packages (and other contributions, including suggestions
on this mailing list) that haven't been provided by SchedMD have
probably been provisioned and tested by a volunteer -- be sure
to keep the conversation civil!</li>
</ol>
<p>Andy Riebs<br>
</p>
<div class="moz-cite-prefix">On 1/25/2021 2:47 AM, Ole Holm Nielsen
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:4857f213-79ec-80c8-3e98-a3e703070dec@fysik.dtu.dk">On
1/23/21 9:43 PM, Philip Kovacs wrote:
<br>
<blockquote type="cite">I can assure you it was easier for you to
filter slurm from your repos than it was for me to make them
available to both epel7 and epel8.
<br>
<br>
No good deed goes unpunished I guess.
<br>
</blockquote>
<br>
I do sympathize with your desire to make the Slurm installation a
bit easier by providing RPMs via the EPEL repo. I do not
underestimate the amount of work it takes to add software to EPEL.
<br>
<br>
However, I have several issues with your approach:
<br>
<br>
1. Breaking existing Slurm installations could cause big time
problems at a lot of sites! The combined work to repair broken
installations at many sites might be substantial. Sites who are
more than two releases behind 20.11 could end up with
dysfunctional clusters. You are undoubtedly aware that 20.11.3
fixes a major problem in 20.11.2 wrt. OpenMPI, so the upgrade from
20.02 to 20.11.2 may cause problems.
<br>
<br>
2. Your EPEL RPMs *must not* upgrade between major Slurm releases,
like the 20.02 to 20.11 upgrade that almost happened at our site!
I refer again to the delicate upgrade procedure described in
<a class="moz-txt-link-freetext" href="https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm">https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm</a>
<br>
<br>
3. You could have solicited advice from the slurm-users list
before planning your EPEL Slurm packages.
<br>
<br>
4. How do you plan to keep updating future Slurm minor versions on
EPEL in a timely fashion?
<br>
<br>
5. How did you build your RPM packages? The built-in options may
be important, for example, this might be recommended:
<br>
$ rpmbuild -ta slurm-xxx.tar.bz2 --with mysql --with slurmrestd
<br>
<br>
6. Building Slurm RPM packages is actually a tiny part of what it
takes to install Slurm from scratch. There are quite a number of
prerequisites and other things to set up besides the RPMs, see
<br>
<a class="moz-txt-link-freetext" href="https://wiki.fysik.dtu.dk/niflheim/Slurm_installation">https://wiki.fysik.dtu.dk/niflheim/Slurm_installation</a>
<br>
plus configuration of Slurm itself and its database.
<br>
<br>
In conclusion, I would urge you to ensure that your EPEL packages
won't mess up existing Slurm installations! I agree with Ryan
Novosielski that you should rename your RPMs so that they don't
overwrite packages built by SchedMD's rpmbuild system.
<br>
<br>
I propose that you add the major version 20.11 right after the
"slurm" name so that your EPEL RPMs would be named "slurm-20.11-*"
like in:
<br>
<br>
slurm-20.11-20.11.2-2.el7.x86_64
<br>
<br>
People with more knowledge of RPM than I have could help you
ensure that no unwarranted upgrades or double Slurm installations
can take place.
<br>
<br>
Thanks,
<br>
Ole
<br>
<br>
<br>
<blockquote type="cite">On Saturday, January 23, 2021, 07:03:08 AM
EST, Ole Holm Nielsen <a class="moz-txt-link-rfc2396E" href="mailto:ole.h.nielsen@fysik.dtu.dk"><ole.h.nielsen@fysik.dtu.dk></a> wrote:
<br>
<br>
<br>
We use the EPEL yum repository on our CentOS 7 nodes. Today
EPEL
<br>
surprisingly delivers Slurm 20.11.2 RPMs, and the daily yum
updates
<br>
(luckily) fail with some errors:
<br>
<br>
--> Running transaction check
<br>
---> Package slurm.x86_64 0:20.02.6-1.el7 will be updated
<br>
--> Processing Dependency: slurm(x86-64) = 20.02.6-1.el7 for
package:
<br>
slurm-libpmi-20.02.6-1.el7.x86_64
<br>
--> Processing Dependency: libslurmfull.so()(64bit) for
package:
<br>
slurm-libpmi-20.02.6-1.el7.x86_64
<br>
---> Package slurm.x86_64 0:20.11.2-2.el7 will be an update
<br>
--> Processing Dependency: pmix for package:
slurm-20.11.2-2.el7.x86_64
<br>
--> Processing Dependency: libfreeipmi.so.17()(64bit) for
package:
<br>
slurm-20.11.2-2.el7.x86_64
<br>
--> Processing Dependency: libipmimonitoring.so.6()(64bit)
for package:
<br>
slurm-20.11.2-2.el7.x86_64
<br>
--> Processing Dependency: libslurmfull-20.11.2.so()(64bit)
for package:
<br>
slurm-20.11.2-2.el7.x86_64
<br>
---> Package slurm-contribs.x86_64 0:20.02.6-1.el7 will be
updated
<br>
---> Package slurm-contribs.x86_64 0:20.11.2-2.el7 will be an
update
<br>
---> Package slurm-devel.x86_64 0:20.02.6-1.el7 will be
updated
<br>
---> Package slurm-devel.x86_64 0:20.11.2-2.el7 will be an
update
<br>
---> Package slurm-perlapi.x86_64 0:20.02.6-1.el7 will be
updated
<br>
---> Package slurm-perlapi.x86_64 0:20.11.2-2.el7 will be an
update
<br>
---> Package slurm-slurmdbd.x86_64 0:20.02.6-1.el7 will be
updated
<br>
---> Package slurm-slurmdbd.x86_64 0:20.11.2-2.el7 will be an
update
<br>
--> Running transaction check
<br>
---> Package freeipmi.x86_64 0:1.5.7-3.el7 will be installed
<br>
---> Package pmix.x86_64 0:1.1.3-1.el7 will be installed
<br>
---> Package slurm.x86_64 0:20.02.6-1.el7 will be updated
<br>
--> Processing Dependency: slurm(x86-64) = 20.02.6-1.el7 for
package:
<br>
slurm-libpmi-20.02.6-1.el7.x86_64
<br>
--> Processing Dependency: libslurmfull.so()(64bit) for
package:
<br>
slurm-libpmi-20.02.6-1.el7.x86_64
<br>
---> Package slurm-libs.x86_64 0:20.11.2-2.el7 will be
installed
<br>
--> Finished Dependency Resolution
<br>
Error: Package: slurm-libpmi-20.02.6-1.el7.x86_64
<br>
(@/slurm-libpmi-20.02.6-1.el7.x86_64)
<br>
Requires: libslurmfull.so()(64bit)
<br>
Removing: slurm-20.02.6-1.el7.x86_64
<br>
(@/slurm-20.02.6-1.el7.x86_64)
<br>
libslurmfull.so()(64bit)
<br>
Updated By: slurm-20.11.2-2.el7.x86_64 (epel)
<br>
Not found
<br>
Error: Package: slurm-libpmi-20.02.6-1.el7.x86_64
<br>
(@/slurm-libpmi-20.02.6-1.el7.x86_64)
<br>
Requires: slurm(x86-64) = 20.02.6-1.el7
<br>
Removing: slurm-20.02.6-1.el7.x86_64
<br>
(@/slurm-20.02.6-1.el7.x86_64)
<br>
slurm(x86-64) = 20.02.6-1.el7
<br>
Updated By: slurm-20.11.2-2.el7.x86_64 (epel)
<br>
slurm(x86-64) = 20.11.2-2.el7
<br>
You could try using --skip-broken to work around the problem
<br>
You could try running: rpm -Va --nofiles --nodigest
<br>
<br>
<br>
We still run Slurm 20.02 and don't want EPEL to introduce any
Slurm
<br>
updates!! Slurm must be upgraded with some care, see for
example
<br>
<a class="moz-txt-link-freetext" href="https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm">https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm</a>
<a class="moz-txt-link-rfc2396E" href="https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm"><https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm></a><br>
<br>
Therefore we must disable EPEL's slurm RPMs permanently. The
fix is to
<br>
add to the file /etc/yum.repos.d/epel.repo an "exclude=slurm*"
line like
<br>
the last line in:
<br>
<br>
[epel]
<br>
name=Extra Packages for Enterprise Linux 7 - $basearch
<br>
#baseurl=<a class="moz-txt-link-freetext" href="http://download.fedoraproject.org/pub/epel/7/$basearch">http://download.fedoraproject.org/pub/epel/7/$basearch</a>
<a class="moz-txt-link-rfc2396E" href="http://download.fedoraproject.org/pub/epel/7/$basearch"><http://download.fedoraproject.org/pub/epel/7/$basearch></a>
<br>
metalink=<a class="moz-txt-link-freetext" href="https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch&infra=$infra&content=$contentdir">https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch&infra=$infra&content=$contentdir</a>
<a class="moz-txt-link-rfc2396E" href="https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch&infra=$infra&content=$contentdir"><https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch&infra=$infra&content=$contentdir></a>
<br>
failovermethod=priority
<br>
enabled=1
<br>
gpgcheck=1
<br>
gpgkey=<a class="moz-txt-link-freetext" href="file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7">file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7</a>
<br>
exclude=slurm*
<br>
<br>
/Ole
<br>
<br>
</blockquote>
<br>
</blockquote>
</body>
</html>