I think the crux of this issue isn't necessarily that EPEL is now
providing Slurm packages, but that when they were made available it took
an EPEL user by surprise.
EPEL maintains multiple mailing lists:
https://fedoraproject.org/wiki/EPEL#Communicating_with_the_EPEL_SIG
Searching through that list, I quickly found announcements that Slurm
202.11.2 was added to EPEL 7 and EPEL 8 on Friday evening:
https://lists.fedoraproject.org/archives/list/epel-package-annou...@lists.fedoraproject.org/message/2NOE6TYZKUCRYEY4Z754IGHAORRZG6SC/
https://lists.fedoraproject.org/archives/list/epel-package-annou...@lists.fedoraproject.org/message/KPO7IONLWK627CTAG2JWBEIOE7LCK7BQ/
These announcements indicate that this addition to EPEL was in response
to a user request:
https://bugzilla.redhat.com/show_bug.cgi?id=1912491
While I have to admit the timing of the announcements was very
unfortunate (it was the weekend, when no one would probably see the
announcements until Monday, when it might have been too late to
intervene), I think we as system administrators need to take some
responsibility for the software we install on our systems, and if we use
EPEL, we should probably subscribe to EPEL's announcement lists to
reduce/minimize surprises like this. I admit I don't subscribe to EPEL's
mailing lists myself, but I'm about to subscribe right now as a result
of this discussion.
Also, I have to echo the comments from others in this discussion that
automatic updates on production systems is not a good idea. Yes, our
Cybersecurity departments want us to do it, but they're not the ones who
have to deal with applications that suddenly stop working when an
automatic update breaks something.
Also, I'm glad someone was able to find this problem before it caused an
issue for them or anyone else and they were able to warn the rest of us,
so thanks for the warning!
Personally, I think it's good that Slurm RPMs are now available through
EPEL, although I won't be able to use them, and I'm sure many people on
the list won't be able to either, since licensing issues prevent them
from providing support for NVIDIA drivers, so those of us with GPUs on
our clusters will still have to compile Slurm from source to include
NVIDIA GPU support.
Prentice
On 1/25/2021 8:00 PM, gil...@rist.or.jp wrote:
Folks,
Tina made excellent points on why EPEL packaging SLURM is a good thing
and I am not going to re-iterate them.
Instead, I acknowledge Philip Kovacs positive contribution to those who
simply hoped for a "hassle free single node SLURM cluster to start with"
For some reasons [I do not understand], some chose to translate "I do
not want to use EPEL SLURM
packages [on my cluster]" into "EPEL should not package SLURM".
Do not get me wrong, there are many legit reasons why one would not want
to use SLURM from EPEL, and the points have already been made. That
being said, the two previous statements are not logically equivalent,
and using local vs EPEL packages should in my opinion remain a site
policy and should not impact EPEL volunteers/packagers/maintainers.
As far as I am concerned, I believe using yum-plugin-priorities (
replaced by dnf from RHEL8) is a superior solution if one wants to
prefer using site packages (and this is not limited to SLURM) instead of
those provided by third party repositories.
Running "daily yum update" on "production HPC clusters that need to stay
very stable" is in my not so humble opinion a step in the opposite
direction.
A workflow that did not anticipate third party repositories (such as
EPEL) could start providing packages that conflict with packages built
on site (such as SLURM) is a workflow that was flawed since the
beginning.
This was recently evidenced by EPEL, so let's avoid blaming the
messenger:
[SLURM RPMs from] EPEL did not "upset" any "stable scenario".
Asking EPEL to rename the SLURM packages would cause some different
issues, for example when EPEL starts providing packages that depend on
SLURM.
But if one believes this is the best option, eating own dog food should
always be on the table: rename local SLURM packages (since SchedMD does
not provide any RPMs).
Regardless the technical aspects, and from a pure OSS philosophical
point of view, asking EPEL to make such changes for one's self
convenience seems pretty wrong to me.
Cheers,
Gilles
----- Original Message -----
That is basically how I do it.
I created a local repository for the packages I build (slurm and any
other, like openmpi). This provides as much control as I could
possibly
need/want. I can name them how I like to avoid conflict with any
external repositories.
I think it is a good idea to have them in EPEL for so many folks that
just want to try the basic setup. This is how we get adoption by more
people. As they learn and want more, they can start building their own
with any options they desire.
Also, a plug for support contracts. I have been doing slurm for a very
long while, but always encourage my clients to get a support contract.
That is how SchedMD stays alive and we are able to have such a good
piece of software. I see the cloud providers starting to build tools
that will eventually obsolesce slurm for the cloud. I worry that there
won't be enough paying customers for Tim to keep things running as
well
as he has. I'm pretty sure most folks that use slurm for any period of
time has received more value that a small support contract would be.
Brian Andrus
On 1/25/2021 7:35 AM, Jeffrey T Frey wrote:
...I would say having SLURM rpms in EPEL could be very helpful for
a lot of people.
I get that this took you by surprise, but that's not a reason to
not have them in the repository. I, for one, will happily test if they
work for me, and if they do, that means that I can stop having to build
them. I agree it's not hard to do, but if I don't have to do it I'll be
very happy about that.
There have been plenty of arguments for why having them in EPEL isn'
t necessarily the best option. Many open source products (e.g. Postgres,
Docker) maintain their own YUM repository online -- probably to
exercise greater control over what's published, but also to avoid
overlap with mainstream package repositories. If there is value
perceived in having pre-built packages available, then perhaps the best
solution for all parties is to publish the packages to a unique
repository: those who want the pre-built packages explicitly configure
their YUM to pull from that repository, those who have EPEL configured (
which is a LOT of us) don't get overlapping Slurm packages interfering
with their local builds.
::::::::::::::::::::::::::::::::::::::::::::::::::::::
Jeffrey T. Frey, Ph.D.
Systems Programmer V & Cluster Management
IT Research Cyberinfrastructure
& College of Engineering
University of Delaware, Newark DE 19716
Office: (302) 831-6034 Mobile: (302) 419-4976
::::::::::::::::::::::::::::::::::::::::::::::::::::::
