rc94 discussion (mid-April 2021?)

[kolyshkin]

After releasing rc93, we are in feature freeze, i.e. only bug fixes¹ are accepted into rc94,
which (hopefully) will be the last rc before the final 1.0 release.

Issues and PRs targeted for rc94 need to be added to 1.0.0-rc94 milestone

• changes since rc93: v1.0.0-rc93...master
• PRs targeted for rc94
• PRs targeted for rc94 with impact/changelog label

¹ I want to make an exception for CI improvements, as those do not directly affect the code,
but might result in better quality/coverage/etc. Maybe also trivial features such as #2789.

[cyphar]

Yeah, i'm fine with CI changes. Feature freeze doesn't include things like documentation and CI. Also depending on Docker's testing we might be able to skip rc94 entirely.

[JonathonReinhart]

Am I too late for #2826 to be considered for v1.0.0?

[h-vetinari]

Mid-march has arrived - there's still a fair amount of open PRs in the milestone. Biggest unknown seems to be #2797, which doesn't have a PR yet.

PS. June 4th is the 5th birthday of 1.0.0-rc1, would be fun if 1.0.0 could/would be released on that date 🙃

[cyphar]

I should have a PR for #2797 ready next week or so -- I was on vacation hence the lack of work on it. 😉

EDIT: Ah, next week is hackweek. I will work on it the week after.

[elldritch]

Is there an ETA for the rc94 release? I'm particularly interested in #2801 (comment) since I'm on Arch and Docker is just straight up broken for me until this patch is released. If the release is soon, I'll just wait for it, but if it's far off, I'm going to look at messing with my kernel parameters instead.

[kolyshkin]

Just talked to @cyphar -- it seems it makes sense to release rc94 before the cgroup v2 device changes he is working on are ready, as we already have a decent amount of fixes; that includes a fix for regression in rc93 (issues #2865, #2828, presumably fixed by PR #2871).

Let's try to merge the remaining PRs with the rc94 milestone and prepare a release.

[cyphar]

Yup, I can cook up a release with those fixes once they're merged.

[AkihiroSuda]

SGTM

[haircommander]

any opposition to adding #2894 (fixes a regression between rc92 and rc93)

[mrunalp]

SGTM

[cyphar]

Only big thing remaining is #2896.

[kolyshkin]

I'd like to have #2897 included as this fixes a real bug (albeit not a regression) and I'd rather have the fix being tested in rc94.

[h-vetinari]

It seems the usual** "just one more PR" also applies to this release, but the end seems to be in sight now - how about pushing this over the finish line?

** by "usual", I don't mean runc, but OSS 😅

[tao12345666333]

SGTM
Looking at milestone 1.0.0-rc94 , we will find that only #2906 is left now. Will we release rc94 after #2906 is completed?

[AkihiroSuda]

We want to fix the performance regression in rc93 before releasing rc94: #2921

[cyphar]

Everything is merged. I will prepare a release PR on top of d279ebd.

[kolyshkin]

For the changelog, this is what I have based only on impact/changelog labels set:

Potentially breaking changes:

• cgroupv1: kernel memory limits are now ignored (Ignore kernel memory settings #2840)
• libcontainer/cgroups: cgroup managers' Set now accept configs.Resources rather than configs.Cgroups (libct/cg: make Set accept configs.Resources #2906)
• libcontainer/cgroups/systemd: reconnect and retry in case dbus connection is closed (after dbus restart) (libct/cg/sd: reconnect and retry on dbus connection error #2923)
• libcontainer/cgroups/systemd: don't set limits in Apply (libct/cgroups/systemd: don't set limits in Apply #2814)

Bugfixes:

• seccomp: fix 32-bit compilation errors (regression in rc93, 32-bit related seccomp issues #2783)
• cgroupv2: blkio weight value conversion fix (Do not convert blkio weight value using blkio->io conversion scheme #2786)
• runc init: fix a hang caused by deadlock in seccomp/ebpf loading code (regression in rc93, Ensure the seccomp pipe is being read while exporting bpf (regression in rc93) #2871)
• runc start: fix "chdir to cwd: permission denied" for some setups (regression in rc93, libct/init_linux: retry chdir to fix EACCES (regression in rc93) #2894)
• s390: fix broken terminal (regression in rc93, vendor: bump containerd/console to 1.0.2 #2898)

Improvements:

• runc start/exec: better diagnostics when container limits are too low (Better handle hitting the memory limit #2812)
• runc start/exec: better cleanup after failed runc init (Avoid killing runc init early #2855)
• cgroupv1: improve freezing chances (freezer: add delay after freeze #2941, libct/cg/fs/freezer: make sure to thaw on failure #2918, cgroupv1 freezer: thaw to increase freeze chances #2791)
• cgroupv2: multiple GetStats improvements (Fix memory stats for cache in fs2 #2816, libct/cg/fs2.GetStats() improvements #2873)
• cgroupv2: fallback to setting io.weight if io.bfq.weight is not available (fs2: fallback to setting io.weight if io.bfq.weight #2820)
• capabilities: WARN, not ERROR, for unknown / unavailable capabilities (capabilities: WARN, not ERROR, for unknown / unavailable capabilities #2854)

[cpuguy83]

Callout for #2928 ?

[cyphar]

It would be nice if we'd have a proper CHANGELOG.md so I didn't have to write one from scratch each time.

[h-vetinari]

It would be nice if we'd have a proper CHANGELOG.md so I didn't have to write one from scratch each time.

Ummmmm... #2368. I offered to do this (including backfilling for a few releases using a to-be-agreed format), but the appetite was very low.

[cyphar]

Yeah I remember the issue, the problem was that back-filling the changelog with prettified git log messages isn't quite ideal. Back-filling it with the actual release notes is probably more useful to be honest. But I don't even think we need to backfill it, we could just start a new changelog from scratch with the next release and add stuff with each PR.

[h-vetinari]

[...] back-filling the changelog with prettified git log messages isn't quite ideal. Back-filling it with the actual release notes is probably more useful to be honest.

That was the only starting point; could have been brought into better shape (e.g. the format in the linked comment) during the PR, and including previous release notes would be trivial.

[kolyshkin]

It would be nice if we'd have a proper CHANGELOG.md so I didn't have to write one from scratch each time.

My proposal is to

1. Have impact/changelog label for every PR that is worth mentioning (bug fix, notable improvement, new feature, potentially breaking change etc).
2. Have a "Changelog entry" field in such PRs.
3. collect those entries before the release.

This is sort of what I did. Was not perfect but AFAICS it works.

[tao12345666333]

I agree with @kolyshkin ‘s proposal. We can reach an agreement during the PR merger without having to count again afterwards.

[cyphar]

v1.0.0-rc94 has been released. https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc94

[h-vetinari]

Very happy to see - congrats everyone! 🥳😊

Just slightly surprised that there was no wording about the imminent 1.0.0 release? rc93 had this to say:

This is the last feature-rich RC release and we are in a feature-freeze until 1.0. 1.0.0~rc94 will be released in a few weeks with minimal bug fixes only, and 1.0.0 will be released soon afterwards.

... so I would have expected something along the lines of "If no critical regressions are found in the next X weeks, rc94 will be released as runc 1.0.0 on Y (allowing for trivial bugfixes & CI improvements)."

(on a less serious note, let me reiterate the suggestion that Y should be the 3th of June for celebratory reasons 🙃)

commit 04f275d4601ca7e5ff9460cec7f65e8dd15443ec (tag: v1.0.0-rc1)
Author: Michael Crosby <[email protected]>
Date:   Fri Jun 3 15:25:47 2016 -0700

    Update runc version to 1.0.0-rc1

    Signed-off-by: Michael Crosby <[email protected]>

[cyphar]

I think I've decided that saying it will not have any new features is just jinxing it (I've been saying it for almost 2 years now I think).

[h-vetinari]

I think I've decided that saying it will not have any new features is just jinxing it (I've been saying it for almost 2 years now I think).

It's been a long road indeed, yet before there was always some big thing (spec-compliance, hooks, cgroups v2, etc.) for which all other work could not reasonably be blocked. Now would IMO be an excellent opportunity to nail this down and not allow further feature creep.

[cyphar]

@h-vetinari The reason I didn't put that note is because I knew we would be doing another release today to fix the CVE. There are only two PRs in the 1.0.0 milestone, we will do a release once they are merged (barring any other critical fixes).

[h-vetinari]

The reason I didn't put that note is because I knew we would be doing another release today to fix the CVE

Makes complete sense, but I couldn't know that 😅

There are only two PRs in the 1.0.0 milestone, we will do a release once they are merged

Very happy to hear it, amazing to see this (leg of the) journey come to an end! 😊