[slurm-users] Exclude Slurm packages from the EPEL yum repository
mercan
ahmet.mercan at uhem.itu.edu.tr
Mon Jan 25 14:14:32 UTC 2021
Hi;
We are using the yumlock feature of the yum to protect unwanted upgrade
of the some packages. Also, Ole mentioned "exclude=slurm" option of the
repo file. It is not a solutionless problem. But, the package maintainer
is a valued resource which hard to find.
Regards,
Ahmet M.
25.01.2021 16:59 tarihinde Andy Riebs yazdı:
>
> Several things to keep in mind...
>
> 1. 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.
> 2. If you really want a closely managed source for your Slurm RPMs,
> get them from the SchedMD website.
> 3. "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."
> 4. 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!
>
> Andy Riebs
>
> On 1/25/2021 2:47 AM, Ole Holm Nielsen wrote:
>> On 1/23/21 9:43 PM, Philip Kovacs wrote:
>>> 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.
>>>
>>> No good deed goes unpunished I guess.
>>
>> 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.
>>
>> However, I have several issues with your approach:
>>
>> 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.
>>
>> 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
>> https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm
>>
>> 3. You could have solicited advice from the slurm-users list before
>> planning your EPEL Slurm packages.
>>
>> 4. How do you plan to keep updating future Slurm minor versions on
>> EPEL in a timely fashion?
>>
>> 5. How did you build your RPM packages? The built-in options may be
>> important, for example, this might be recommended:
>> $ rpmbuild -ta slurm-xxx.tar.bz2 --with mysql --with slurmrestd
>>
>> 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
>> https://wiki.fysik.dtu.dk/niflheim/Slurm_installation
>> plus configuration of Slurm itself and its database.
>>
>> 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.
>>
>> 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:
>>
>> slurm-20.11-20.11.2-2.el7.x86_64
>>
>> People with more knowledge of RPM than I have could help you ensure
>> that no unwarranted upgrades or double Slurm installations can take
>> place.
>>
>> Thanks,
>> Ole
>>
>>
>>> On Saturday, January 23, 2021, 07:03:08 AM EST, Ole Holm Nielsen
>>> <ole.h.nielsen at fysik.dtu.dk> wrote:
>>>
>>>
>>> We use the EPEL yum repository on our CentOS 7 nodes. Today EPEL
>>> surprisingly delivers Slurm 20.11.2 RPMs, and the daily yum updates
>>> (luckily) fail with some errors:
>>>
>>> --> Running transaction check
>>> ---> Package slurm.x86_64 0:20.02.6-1.el7 will be updated
>>> --> Processing Dependency: slurm(x86-64) = 20.02.6-1.el7 for package:
>>> slurm-libpmi-20.02.6-1.el7.x86_64
>>> --> Processing Dependency: libslurmfull.so()(64bit) for package:
>>> slurm-libpmi-20.02.6-1.el7.x86_64
>>> ---> Package slurm.x86_64 0:20.11.2-2.el7 will be an update
>>> --> Processing Dependency: pmix for package: slurm-20.11.2-2.el7.x86_64
>>> --> Processing Dependency: libfreeipmi.so.17()(64bit) for package:
>>> slurm-20.11.2-2.el7.x86_64
>>> --> Processing Dependency: libipmimonitoring.so.6()(64bit) for package:
>>> slurm-20.11.2-2.el7.x86_64
>>> --> Processing Dependency: libslurmfull-20.11.2.so()(64bit) for
>>> package:
>>> slurm-20.11.2-2.el7.x86_64
>>> ---> Package slurm-contribs.x86_64 0:20.02.6-1.el7 will be updated
>>> ---> Package slurm-contribs.x86_64 0:20.11.2-2.el7 will be an update
>>> ---> Package slurm-devel.x86_64 0:20.02.6-1.el7 will be updated
>>> ---> Package slurm-devel.x86_64 0:20.11.2-2.el7 will be an update
>>> ---> Package slurm-perlapi.x86_64 0:20.02.6-1.el7 will be updated
>>> ---> Package slurm-perlapi.x86_64 0:20.11.2-2.el7 will be an update
>>> ---> Package slurm-slurmdbd.x86_64 0:20.02.6-1.el7 will be updated
>>> ---> Package slurm-slurmdbd.x86_64 0:20.11.2-2.el7 will be an update
>>> --> Running transaction check
>>> ---> Package freeipmi.x86_64 0:1.5.7-3.el7 will be installed
>>> ---> Package pmix.x86_64 0:1.1.3-1.el7 will be installed
>>> ---> Package slurm.x86_64 0:20.02.6-1.el7 will be updated
>>> --> Processing Dependency: slurm(x86-64) = 20.02.6-1.el7 for package:
>>> slurm-libpmi-20.02.6-1.el7.x86_64
>>> --> Processing Dependency: libslurmfull.so()(64bit) for package:
>>> slurm-libpmi-20.02.6-1.el7.x86_64
>>> ---> Package slurm-libs.x86_64 0:20.11.2-2.el7 will be installed
>>> --> Finished Dependency Resolution
>>> Error: Package: slurm-libpmi-20.02.6-1.el7.x86_64
>>> (@/slurm-libpmi-20.02.6-1.el7.x86_64)
>>> Requires: libslurmfull.so()(64bit)
>>> Removing: slurm-20.02.6-1.el7.x86_64
>>> (@/slurm-20.02.6-1.el7.x86_64)
>>> libslurmfull.so()(64bit)
>>> Updated By: slurm-20.11.2-2.el7.x86_64 (epel)
>>> Not found
>>> Error: Package: slurm-libpmi-20.02.6-1.el7.x86_64
>>> (@/slurm-libpmi-20.02.6-1.el7.x86_64)
>>> Requires: slurm(x86-64) = 20.02.6-1.el7
>>> Removing: slurm-20.02.6-1.el7.x86_64
>>> (@/slurm-20.02.6-1.el7.x86_64)
>>> slurm(x86-64) = 20.02.6-1.el7
>>> Updated By: slurm-20.11.2-2.el7.x86_64 (epel)
>>> slurm(x86-64) = 20.11.2-2.el7
>>> You could try using --skip-broken to work around the problem
>>> You could try running: rpm -Va --nofiles --nodigest
>>>
>>>
>>> We still run Slurm 20.02 and don't want EPEL to introduce any Slurm
>>> updates!! Slurm must be upgraded with some care, see for example
>>> https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm
>>> <https://wiki.fysik.dtu.dk/niflheim/Slurm_installation#upgrading-slurm>
>>>
>>> Therefore we must disable EPEL's slurm RPMs permanently. The fix is to
>>> add to the file /etc/yum.repos.d/epel.repo an "exclude=slurm*" line
>>> like
>>> the last line in:
>>>
>>> [epel]
>>> name=Extra Packages for Enterprise Linux 7 - $basearch
>>> #baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
>>> <http://download.fedoraproject.org/pub/epel/7/$basearch>
>>> metalink=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>
>>>
>>> failovermethod=priority
>>> enabled=1
>>> gpgcheck=1
>>> gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
>>> exclude=slurm*
>>>
>>> /Ole
>>>
>>
More information about the slurm-users
mailing list