20.02.1 track creation for Slurm

store
1

We (Omnivector Solutions) want to begin releasing our Snap using the versioning scheme used by Slurm so we are requesting a new track called 20.02.1.

Thanks!

1 Like
2

Hi there!

Hello,

First-time track requests follow Process for aliases, auto-connections and tracks, meaning we will have a 7-day waiting period to allow for reviewers to inspect the request and cast their votes.

The main criteria for tracks is backward-incompatibility between releases of your software, particularly if people do have a legitimate reason to want to choose an older version over the new one.

For example, if it involves invasive code changes, or has a different data format, and there’s no easy migration/conversion tool that people could use with a new release.

Can you please indicate whether this is the case with your software?

Another thing we ask for is a reasonable lifetime for releases. If you’re releasing an incompatible version every 2 weeks, tracks would be a poor fit as you would be stranding a lot of people on older releases as you move ahead. This typically indicates your software is still evolving and tracks are really best suited for mature, stable projects.

If you have a link or documentation to your project’s release schedule/cadence, that will be useful for reviewers.

For slurm I’m specifically curious about the versioning scheme, it has too many dots :slight_smile: and usually patch releases are not a good fit for tracks. Can you explain what 20.02.1 indicates, when the next release should come out, and what the next version number would be?

Thanks and apologies for asking so many questions :slight_smile:

  • Daniel
3

Hey Roadmr,

Slurm doesn’t really follow a traditional semantic versioning schedule, so using minor or “maintenance” releases as a way to gauge backward compatibility isn’t very reliable.

Due to the nature of Slurm, upgrades are typically deliberate and may cause outages depending on the host configuration.

As such, if a consumer wishes to use Slurm version 20.02.1, they most likely do not want to auto-upgrade to version 20.02.2 as it may cause unintended outages or even corrupt their SlurmDBD database.

Furthermore, nearly every major release involves changes to the state files which, on a live system, may result in the loss of running and or pending jobs.

Here’s a link to the current Release Notes and here’s a link to special notes about upgrading Slurm versions.

The tl;dr of it is: An unintended or unexpected upgrade of Slurm, even a minor upgrade, could cause a consumer’s nodes to go offline which is undesirable if not unacceptable in HPC use cases.

Let me know if you have any other questions!

4

Thanks for the detailed info!

+1 from me on 20.02.1 track. We’ll allow a couple of more days for comments/votes.

Thanks!

  • Daniel
1 Like
5

+1 on a 20.02.1 track.

1 Like
6

Is there anything else I need to do for this?

7

Hi! Sorry! This request fell through the usual crack ;( I’ve now created the 20.02.1 track for slurm.

Cheers!

  • Daniel
8

Very good, thank you!

9

@roadmr would it be possible to amend this request or should I create a new request?

There is a need for us to have a simple 20.02 to auto-upgrade the maintenance releases. This is useful because Slurm maintenance releases are irregular and we don’t want to block subscribers from upgrading while we request another track and bake it into our CI pipeline.

10

Totally. I can create 20.02 using the simplified procedure so it’ll be quicker.

I’d just like to confirm how you intend to use it and how it relates to the 20.02.1 track we created earlier.

I think the pattern would be:

if I want 20.02.1 and to stay on that one, I use the 20.02.1 track.

If I want 20.02.1 now and then to auto-upgrade to 20.02.2 and subsequent, I use the 20.02 track.

Does that sound correct? if so, is there a reason you wouldn’t want to use the existing “latest” track for this? i.e. is it likely someone would want to stay within the 20.02 series but not say 20.03 when that is released?

I’m asking because it sounds like the scheme you’re proposing will create a proliferation of tracks, it’s not entirely intractable but keep in mind it might be confusing for users to have all those choices when they do “snap info”.

  • Daniel
11

So the tl;dr of it is I’m the maintainer of the Slurm Snap so I have to keep an eye on the upstream mailing lists. When there’s a new point release, I’ll have to make a new request here and it feels a little thrashy to be making new requests every month or so :sweat_smile:

I confirmed with upstream that point releases (maintenance releases) don’t have the backward compatibility issue that I initially thought so these “auto-upgrades” are relatively low-risk.

Does that sound correct? if so, is there a reason you wouldn’t want to use the existing “latest” track for this?

Because when upstream releases a new major version, consumers of our Snap do not want to be auto-upgraded to it. if we use the latest track and we push a major upgrade to it, it would cause major issues.

12

hm didn’t you mean they “do” have the backward compatibility? otherwise updating to a non-compatible point release does sound high-risk to me :slight_smile:

Creating a track a month is not intractable if that fits better the projects’ release cadence and compatibility guarantees; no worries, it takes 5 minutes on our side since there already existing tracks which mean we have already gone through the “how do your tracks work?” discussion.

  • Daniel
13

Whoops yes, I edited my post. Didn’t mean to double negative it! Yes, maintenance releases are relatively low-risk but the major releases are very high risk for obvious reasons.

Creating a track a month is not intractable if that fits better the projects’ release cadence

Okay, if this is the best practice, we can stick with it. But does this exclude having a regular 20.02 track too for those that wish to get regular maintenance releases but not major releases?

14

Not necessarily. If it fits your release cadence (i.e. a patch 20.02.x track every month or so, plus a rolling 20.02 track every X months) that’s fine, just keep in mind that you’ll be adding more than a dozen tracks per year, this is likely to confuse users. One thing I would suggest in that case is closing patch tracks aggressively (i.e. once 20.02.2 comes out, people have no more reason to install 20.02.1, right? so close it, or maybe keep two patch releases, so keep 20.02.1 until 20.02.3 comes around) so you only have a few open at any given time.

Let me know if that sounds reasonable/useful.

  • Daniel
15

i.e. a patch 20.02.x track every month or so, plus a rolling 20.02 track every X months

Yeah, this sounds ideal. And we’ll close out the old tracks as time goes on as well. I think this option will work :+1:

16

Awesome. With that agreement/understanding I can go ahead and create 20.02, and later when you request it, 20.02.2.

And if I’m correct, right now you would publish the 20.02.1 revision to the 20.02 track, when 20.02.2 comes along it also goes to the 20.02 track, and so on… while additionally each point rev goes to its own track.

Let me know and I can create the track today or maybe tomorrow.

  • Daniel
1 Like
17

With that agreement/understanding I can go ahead and create 20.02, and later when you request it, 20.02.2.

Yep this will work. Thank you!

18

Thanks! +1 from me as reviewer, and I’ve created the 20.02 track per Simplified track request process for snaps with predictable cadence.

Cheers!

  • Daniel
2 Likes