What you are describing is implemented in the EL ecosystems as module streams.
Streams are setup by maintainersto correspond to major version trains of
software. Users can then select the stream they want and can change streamsas
desired (unfortunately this is often not trivial), without upgra
I am familiar with the package rename process and it would not have the effect
you might think it would.If I provide an upgrade path to a new package name,
e.g. slurm-xxx, the net effect would be to tell yum ordnf-managed systems that
the new package name for slurm is slurm-xxx. That would make
On Wednesday, 03 February 2021, at 18:06:27 (+),
Philip Kovacs wrote:
> I am familiar with the package rename process and it would not have
> the effect you might think it would.If I provide an upgrade path to
> a new package name, e.g. slurm-xxx, the net effect would be to tell
> yum ordnf-ma
My main point here is that essentially upgrading someone from, for example,
SLURM 20.02 to SLURM 20.11 is not desirable, and that’s why upgrades between
major versions, IMO, should not happen automatically. There’s a whole section
of the documentation about how to do this properly, and I’m not s
On 2021-02-03 10:32, Brian Andrus wrote:
Wow,
This is getting so ridiculous that my email program has started
putting this thread in junk...
The spirit of Linux is to give you the tools so you can do things how
you want. You have the tools, do not expect someone else to come over
and plan
Wow,
This is getting so ridiculous that my email program has started putting
this thread in junk...
The spirit of Linux is to give you the tools so you can do things how
you want. You have the tools, do not expect someone else to come over
and plant/maintain your garden. Just because they ca
Hi Phil,
assuming that all sites maintaining their own Slurm rpm packages must
now somehow ensure that these are not replaced by the EPEL packages
anyway, why wouldn't it be possible, in the long run, to follow the
Fedora packaging guidelines for renaming existing packages?
https://docs.fedo
Lots of mixed reactions here, many in favor (and grateful) for the add to
EPEL, many much less enthusiastic.
I cannot rename an EPEL package that is now in the wild without providing an
upgrade path to the new name. Such an upgrade path would defeat the purpose of
the rename and won't help at a
I've definitely been there with the minimum cost issue. One thing I have
done personally is start attending SLUG. Now I can give back and learn
more in the process. That may be an option to pitch, iterating the value
you receive from open source software as part of the ROI.
Interestingly, I ha
Same here - $10k for less than 200 nodes. That's an order of magnitude
which makes the finance people ask what we are getting for the money.
As we don't have any special requirements which would require
customisation, that's not easy to answer, so currently we don't have a
support contract. How
We’re in the same boat. Extremely small cluster. $10k for support. We don’t
need nearly that level of engagement, but there ya go. We’ve passed for
now, but I’d like to have a support contract ideally.
Jason
On Tue, Jan 26, 2021 at 2:49 PM Robert Kudyba wrote:
>
>
> On Mon, Jan 25, 2021 at 6:36
On Mon, Jan 25, 2021 at 6:36 PM Brian Andrus wrote:
> 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 th
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 unde
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 hav
> ...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
See below
On 1/25/2021 9:36 AM, Ole Holm Nielsen wrote:
On 1/25/21 2:59 PM, Andy Riebs wrote:
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, i
Sorry. I really don't want this to be a flame war, but...
...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, a
On 1/25/21 2:59 PM, Andy Riebs wrote:
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
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.202
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 timin
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
easie
Thanks for the heads-up, Ole!
--
B/H
signature.asc
Description: PGP signature
I agree that by and large it’s no big deal, but a suggestion might be to
provide the SLURM as slurm-*- being the set of packages you install,
so that updating between major versions wouldn’t happen by surprise, given how
careful one needs to be with SLURM upgrades — ordering, timing, etc. Virtua
On Sat, 2021-01-23 at 20:43 +, 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.
Thanks for your efforts. Much appreciated.
--
Ian
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.On Saturday, January 23, 2021,
07:03:08 AM EST, Ole Holm Nielsen wrote:
We use the EPEL yum repository on our C
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)
26 matches
Mail list logo
