Prepare / Tag v1.1.0 release

[thaJeztah]

(related to https://github.com/containerd/containerd/pull/4357/files#r448837520)

Runc tagged a new release (v1.0.0-rc91), and is currently depending on a non-tagged version of the runtime-spec. With various distribution packagers requiring tagged releases, and with go modules encouraging consumers to packages to use tagged releases, I'm wondering if a new release should be tagged.

runc is currently consuming 237cc4f, (changes since v1.0.2: v1.0.2...237cc4f), but there's a couple more changes in master (237cc4f...master)

Are there pending pull requests that should be merged before tagging v1.0.3? (perhaps #1046 would be nice to have). tags should be "cheap" so, perhaps not a blocker for a v1.0.3, but suggestions welcome 🤗

@cyphar @crosbymichael @tianon @mrunalp @vbatts

[h-vetinari]

Not to further hold up an already long process, but #1040 should also be very close to finished (just waiting for final review).

[AkihiroSuda]

#1040 should be probably v1.0.4 or later

[thaJeztah]

Given that it's adding new features, #1040 should probably bump the minor version to stick with SemVer (so v1.1.0)

[thaJeztah]

Thinking of that, possibly #1046 warrants a "minor" version bump as well, as it's adding new functionality.

[cyphar]

Yeah, we should tag a 1.0.3. I would like to see #1046 merged (I don't think it makes sense to refer to it as a new feature -- it's just defining Go constants that were already defined by the spec -- though arguably the new hooks we added should've made the last release a 1.1.0). And yeah, #1040 should definitely wait -- I don't want to rush adding more logic to cgroup configuration until we're sure it makes sense.

[mskarbek]

@cyphar what more do you expect from croupv2 work?

[cyphar]

@mskarbek We need to have at least one implementation of it so that we can be sure that the specification changes actually work on real systems, and if they don't work we should go back and fix issues we may find in the specification. In addition, it wouldn't hurt to talk to other container runtimes (such as LXC) to get their feedback since they've supported cgroupv2 for much longer than any OCI runtime.

EDIT: Ignore this section, it's pretty much gibberish. I shouldn't write comments while I'm still half-awake...

And looking at the PR right now, we also need to address how to deal with unknown configuration values. Currently it says that:

Configuration unknown to the runtime MUST still be written to the relevant file.

But also:

The runtime MUST generate an error when the configuration refers to a cgroup controller that is not present or that cannot be enabled.

Which could in theory conflict in the future if there is a controller that requires some extra setup other than writing its name to cgroup.controllers. We need to make sure we don't cause future headaches for ourselves while also allowing people to configure cgroupv2 controllers without needing endless runtime-spec updates (which is why I was on board with the current proposal and have discussed doing it this way off-line for some time).

Remember, once something is in the runtime-spec we cannot remove it (without a major version bump) -- shoe-horning it in would be a mistake.

[AkihiroSuda]

The v1-to-v2 conversion convention can be cherry picked to v1.0.3?

[thaJeztah]

@AkihiroSuda which change is that? Do you have a specific PR?

Looking at the changes since the last release; v1.0.2...8e2f17c, those all (at a glance) look ok for a (v1.0.3) "patch" release. Having that would help projects declare that they require >= v1.0.3 in their go.mod.

[cyphar]

@thaJeztah I think he's referring to the v1-to-v2 conversion text that's in #1040 right now (in other words, should we take the conversion text -- which is something runtimes are already implementing -- and leave the whole unified thing for a separate release).

@AkihiroSuda Since the text for the v1-to-v2 conversion is all gated by SHOULD and MAY, we could merge it now and change it in future releases without breaking backwards compatibility (since it's effectively just a recommendation or option for implementations, respectively). Do runc and crun already implement the semantics described (I haven't been following all of the cgroupv2 work in both projects)?

[AkihiroSuda]

Do runc and crun already implement the semantics described (I haven't been following all of the cgroupv2 work in both projects)?

The v1-to-v2 conversion is already implemented, but the pure unified struct is not.

[thaJeztah]

Thanks for clarifying, yes that sounds reasonable

[giuseppe]

And yeah, #1040 should definitely wait -- I don't want to rush adding more logic to cgroup configuration until we're sure it makes sense.

I'd prefer if it has not to wait so much longer, without #1040 the cgroup v2 support is limited to the same features present in cgroup v1

[rhatdan]

@vbatts @mrunalp @AkihiroSuda @cyphar @crosbymichael Can we get this done?

[cyphar]

@opencontainers/runtime-spec-maintainers Do we want to have #1040 split up now so that we can quickly review and merge the cgroup v1->v2 conversion table?

[thaJeztah]

I think it would make sense to at least prepare a PR for that

[giuseppe]

I'd drop the conversion table completely. Despite being the author of it, I am still not convinced it should be part of the runtime specs. I'd just leave the generic If a controller is enabled on the cgroup v2 hierarchy but the configuration is provided for the cgroup v1 equivalent controller, the runtime MAY attempt a conversion.

[AkihiroSuda]

Let's release v1.0.3 as-is and handle the cgroup v2 stuff separately

[giuseppe]

I've dropped the conversion table, that can be added again later if needed

[AkihiroSuda]

How can we move this forward? @opencontainers/runtime-spec-maintainers

[vbatts]

I can do this, but others could as well. Open a PR of the commit with a version bump and then back to "-dev" (2 commits).
Then send an email to the list with a voting period.

[giuseppe]

I've simplified #1040

Is there any chance it can be reviewed before we cut a new release?

[AkihiroSuda]

#1040 might be still controversial to rush in v1.0.3. Can it be v1.0.4?

btw #1060 seems to need prioritization for v1.0.3

[giuseppe]

#1040 might be still controversial to rush in v1.0.3. Can it be v1.0.4?

I am fine with it

[AkihiroSuda]

#1059 seems also harmless for v1.0.3 and easy to review

[h-vetinari]

Now that #1040 is also in, is there anything still necessary for this?

Looking at the open PRs since 1.0.2:

• Add support for SCMP_ACT_KILL_THREAD #1064 seems like an easy pick
• Add type alias for ContainerState for compatibility #1063 says it's undoing a breaking change
• Add support for time namespace #1062 is probably also not controversial, would be nice to have for linux 5.6+
• Add the specification of seccomp userspace notification #1038 & config: Add DisableSpeculationMitigations #1047 are likely not ready yet

[h-vetinari]

Friendly ping @opencontainers/runtime-spec-maintainers
@crosbymichael @mrunalp @vbatts @dqminh @tianon @hqhq @cyphar

[h-vetinari]

From here, regarding deprecation of KernelMemory (which also happens to be broken on RHEL 7):

@cyphar: We will need to remove it from the runtime-spec too...

EDIT (April '21): Should be done now: #1093, opencontainers/runc#2840

[AkihiroSuda]

@opencontainers/runtime-spec-maintainers
Can we move this forward?

[zhsj]

Any news? Currently most consumers(runc containers/common) are not using the tagged version, which makes the version of the spec meaningless..

[rhatdan]

@kolyshkin @thaJeztah Please cut a release.

[giuseppe]

Please let's merge #1143 before we cut a new release

[kolyshkin]

@kolyshkin @thaJeztah Please cut a release.

Neither me nor @thaJeztah are maintainers of this repo (as of right now, although this is being changed by #1150).

[AkihiroSuda]

@kolyshkin @thaJeztah Please cut a release.

Neither me nor @thaJeztah are maintainers of this repo (as of right now, although this is being changed by #1150).

You both are maintainers now 😃.
Are we ready to cut a release?

[kolyshkin]

Sure, let's cut 1.1.0. It seems that we would need a few PRs to be merged first. Let me work on a milestone.

[AkihiroSuda]

It seems that we would need a few PRs to be merged first. Let me work on a milestone.

Which PRs?

[AkihiroSuda]

@kolyshkin ping 🙏

[h-vetinari]

runtime-spec releases really are a sisyphean story...

There's a bunch of high-quality PRs that would suggest themselves for inclusion, but perhaps the current state of the repo should just be released to finally provide a new baseline, and then focus on getting those PRs merged for another release that's similarly just cut without a lot of ceremony?

It's a pity for those features, but it seems we're stuck in an infinite "just these couple more PRs before we release" cycle.

[AkihiroSuda]

Let's move this forward

• Release v1.1.0-rc.1 #1175

[h-vetinari]

RC has been live for 6 weeks - is there anything in particular that's still necessary to happen for a release?

[AkihiroSuda]

RC has been live for 6 weeks - is there anything in particular that's still necessary to happen for a release?

#1130 (comment)

[AkihiroSuda]

Proposal for releasing v1.1.0-rc.2:

• Release v1.1.0-rc.2 #1192

[utam0k]

Can 1.1.0 include these at a minimum? I am not talking about the next rc.2.

• spec: add scheduler entity #1188
• Add I/O Priority Configuration for process group in Linux Containers #1191

[AkihiroSuda]

Proposal for v1.1.0-rc.3

• Release v1.1.0-rc.3 #1208

This should be the last RC for v1.1.0.

[AkihiroSuda]

If there is no objection, I'd like to propose releasing v1.1 GA very soon.

[utam0k]

👍

[AkihiroSuda]

• Release v1.1.0 #1213

[AkihiroSuda]

https://opencontainers.org/posts/blog/2023-07-21-oci-runtime-spec-v1-1/
https://github.com/opencontainers/runtime-spec/releases/tag/v1.1.0