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

[gilles at rist.or.jp]

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
> > ::::::::::::::::::::::::::::::::::::::::::::::::::::::
> >
> >
> 
>