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