Ticket 4221 - Slurm upgrade support from previous major versions
Summary: Slurm upgrade support from previous major versions
Status: RESOLVED FIXED
Alias: None
Product: Slurm
Classification: Unclassified
Component: Documentation (show other tickets)
Version: 17.02.7
Hardware: Linux Linux
: 4 - Minor Issue
Assignee: Felip Moll
QA Contact:
URL:
Depends on:
Blocks:
 
Reported: 2017-10-04 00:39 MDT by Ole.H.Nielsen@fysik.dtu.dk
Modified: 2017-10-04 10:26 MDT (History)
1 user (show)

See Also:
Site: DTU Physics
Slinky Site: ---
Alineos Sites: ---
Atos/Eviden Sites: ---
Confidential Site: ---
Coreweave sites: ---
Cray Sites: ---
DS9 clusters: ---
Google sites: ---
HPCnow Sites: ---
HPE Sites: ---
IBM Sites: ---
NOAA SIte: ---
NoveTech Sites: ---
Nvidia HWinf-CS Sites: ---
OCF Sites: ---
Recursion Pharma Sites: ---
SFW Sites: ---
SNIC sites: ---
Tzag Elita Sites: ---
Linux Distro: ---
Machine Name:
CLE Version:
Version Fixed: 17.02.8
Target Release: ---
DevPrio: ---
Emory-Cloud Sites: ---


Attachments

Note You need to log in before you can comment on or make changes to this ticket.
Description Ole.H.Nielsen@fysik.dtu.dk 2017-10-04 00:39:24 MDT
The slurm-dev mailing list has a thread about upgrading from old Slurm versions. The documentation page https://slurm.schedmd.com/quickstart_admin.html#upgrade states:

"Slurm daemons will support RPCs and state files from the two previous minor releases (e.g. a version 16.05.x SlurmDBD will support slurmctld daemons and commands with a version of 16.05.x, 15.08.x or 14.11.x)."

I believe the word "minor" is in error and should read "major" (as explained in the ().  Would you kindly edit this word in order to avoid user confusion?

Thanks,
Ole
Comment 1 Felip Moll 2017-10-04 03:26:44 MDT
Hello Ole,

I checked this and the documentation is correct:

16.05.3 is major=16, minor=05, micro=3

Chronological example of releases (where x can be any value from [1-n]):
14.11.x
15.08.x
16.05.x
17.02.x
17.11.x

Two previous minor releases starting on 17.11 are 17.02 and 16.05 despite the fact that from 17.x to 16.x implies a change of major release.

Maybe a better sentence would be just "two previous (non-micro) versions" or "two previous combination of major and minor versions".

The point here is in the time-based release naming schema, we use the first 4 digits as a version and the last digit indicates monthly changes, and we are not using the traditional GNU schema.

We will check the concept internally and update the documentation accordingly.

Thank you,
Felip M
Comment 3 Ole.H.Nielsen@fysik.dtu.dk 2017-10-04 05:22:02 MDT
(In reply to Felip Moll from comment #1)
> Hello Ole,
> 
> I checked this and the documentation is correct:
> 
> 16.05.3 is major=16, minor=05, micro=3
> 
> Chronological example of releases (where x can be any value from [1-n]):
> 14.11.x
> 15.08.x
> 16.05.x
> 17.02.x
> 17.11.x
> 
> Two previous minor releases starting on 17.11 are 17.02 and 16.05 despite
> the fact that from 17.x to 16.x implies a change of major release.
> 
> Maybe a better sentence would be just "two previous (non-micro) versions" or
> "two previous combination of major and minor versions".
> 
> The point here is in the time-based release naming schema, we use the first
> 4 digits as a version and the last digit indicates monthly changes, and we
> are not using the traditional GNU schema.

The documentation's wording "two previous minor releases" is definitely ambiguous.  Perhaps the ambiguity is best resolved by removing the word "minor" in the documentation so it reads "two previous releases".

> We will check the concept internally and update the documentation
> accordingly.

Thanks a lot, every little improvement counts.

/Ole
Comment 7 Felip Moll 2017-10-04 10:26:15 MDT
Hi Ole,

I modified the documentation and it will be available in the next release 17.02.8 and the website will be updated also accordingly.

We removed the "minor" word and kept major as first two digits, so in a 17.02.8 major is 17.02 and micro is 8.

Thank you for your collaboration.

Best Regards.