[slurm-users] [External] Re: Exclude Slurm packages from the EPEL yum repository

Tue Jan 26 16:44:04 UTC 2021

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-announce@lists.fedoraproject.org/message/2NOE6TYZKUCRYEY4Z754IGHAORRZG6SC/

https://lists.fedoraproject.org/archives/list/epel-package-announce@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, gilles at 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
>>> ::::::::::::::::::::::::::::::::::::::::::::::::::::::
>>>
>>>
>>
>
>