Prepare / Tag v1.0.3 (or 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 237cc4f519e2e8f9b235bacccfa8ef5a84df2875, (changes since v1.0.2: https://github.com/opencontainers/runtime-spec/compare/v1.0.2...237cc4f519e2e8f9b235bacccfa8ef5a84df2875), but there's a couple more changes in master (https://github.com/opencontainers/runtime-spec/compare/237cc4f519e2e8f9b235bacccfa8ef5a84df2875...master)

Are there pending pull requests that should be merged before tagging v1.0.3? (perhaps https://github.com/opencontainers/runtime-spec/pull/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 https://github.com/opencontainers/runtime-spec/pull/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; https://github.com/opencontainers/runtime-spec/compare/v1.0.2...8e2f17c5a40b7649c3a9bf262e7723ad85929761, 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 https://github.com/opencontainers/runtime-spec/pull/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 https://github.com/opencontainers/runtime-spec/pull/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]

https://github.com/opencontainers/runtime-spec/pull/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:

• #1064 seems like an easy pick
• #1063 says it's undoing a breaking change
• #1062 is probably also not controversial, would be nice to have for linux 5.6+
• #1038 & #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, https://github.com/opencontainers/runc/pull/2840

[kolyshkin]

So, the story is there was a change in https://github.com/opencontainers/runtime-spec/pull/1058 which broke runtime-tools (https://github.com/opencontainers/runtime-tools/pull/706#discussion_r514976311) and to fix it we need a new release according to https://github.com/opencontainers/runtime-tools/pull/708#issuecomment-672180428.

Can we please tag whatever we have now with a v1.0.3?

[thaJeztah]

It would be good to include https://github.com/opencontainers/runtime-spec/pull/1063 before tagging