search

opencontainers / runc

CLI tool for spawning and running containers according to the OCI specification
https://www.opencontainers.org/
Apache License 2.0
11.77k stars 2.09k forks source link

Blockers for v1.2.0 #4114

Open AkihiroSuda opened 10 months ago

AkihiroSuda commented 10 months ago

Blockers for rc.1 (https://github.com/opencontainers/runc/pull/3963):

Blockers for GA:

Needs discussion (probably deferrable to v1.2.1 or v1.3.0):

@opencontainers/runc-maintainers Feel free to edit this issue

AkihiroSuda commented 10 months ago

We don't have timeline for v1.2.0, but we should try to release v1.2.0 by the end of the year.

kolyshkin commented 10 months ago

Well, we have the 1.2.0 milestone (which I am trying comb through regularly), and everything that's in there is kind of a blocker for 1.2.0.

Feel free to modify milestones for any issues/PRs, but at the very least we have one more blocker:

AkihiroSuda commented 10 months ago

Well, we have the 1.2.0 milestone (which I am trying comb through regularly), and everything that's in there is kind of a blocker for 1.2.0.

Not everything. At least this one can be postponed to v1.3 or later

kolyshkin commented 10 months ago

Not everything.

Well, strictly speaking, everything that is under that milestone needs to either be included into 1.2.0, or be reassigned to a different milestone. Whis is why I said

Feel free to modify milestones for any issues/PRs

cyphar commented 10 months ago

I still think #3985 is needed for 1.2.0. There are several issues with mount propagation (not to mention the serious restriction of idmapped mounts) that are fixed with #3985. We also need #3990 if we want to make sure people scream at us during the -rc1 if it breaks something.

Other than those, I don't have any strong opinions on any remaining PRs.

h-vetinari commented 10 months ago

Blockers for GA: Release runtime-spec v1.1.1

Given that it took well over 3 years to get 1.1.0 finished (incl. half a year from rc1 to GA), is it really necessary (resp. judicious) to block runc 1.2 on a spec-release?

AkihiroSuda commented 10 months ago

Blockers for GA: Release runtime-spec v1.1.1

Given that it took well over 3 years to get 1.1.0 finished (incl. half a year from rc1 to GA), is it really necessary (resp. judicious) to block runc 1.2 on a spec-release?

Necessary, because we have been depending on its main branch:

utam0k commented 7 months ago

This task has been done 👍

Release runtime-spec v1.1.1 v1.2.0 https://github.com/opencontainers/runtime-spec/pull/1242

testinfected commented 4 months ago

Hi guys,

Eagerly waiting for that 1.2 release with fixes on mount options. What do you think is a realistic release date?

Thanks

testinfected commented 3 months ago

Ping

AkihiroSuda commented 3 months ago

I think we are ready to release rc.2, and release GA after verifying compatibility with Docker, containerd, BuildKit, etc.

cc @opencontainers/runc-maintainers

AkihiroSuda commented 3 months ago

Turned out that we need to make a decision on this one too

MaxXor commented 3 months ago

Any ETA when 1.2.0 will be released?

AkihiroSuda commented 3 months ago

Any ETA when 1.2.0 will be released?

As soon as the compatibility issues get resolved

h-vetinari commented 2 months ago

3922 is noted as a blocker here, and a recent comment notes

@kolyshkin: This is going to be implemented via https://github.com/opencontainers/runtime-spec/pull/1253

Since https://github.com/opencontainers/runtime-spec/commit/701738418b9555d5213337a0991fd0ffd6c37808 is not yet in a runtime-spec release, does that mean you'll need another spec release to unblock runc 1.2?

From the peanut gallery: Given that #3922 is a year old already (and the issue apparently exists back until runc 1.0.2 at least), I'm skeptical that this really has to block runc 1.2? After being 28 months behind the originally intended release date, perhaps it would be reasonable to stop the scope-creep and just focus on fixing any remaining hard regressions and then release?

AkihiroSuda commented 2 months ago

Let me move #3922 to the "probably deferrable to v1.2.1 or v1.3.0" list

rata commented 2 months ago

I've tested runc 1.2.0-rc.2 with containerd and opened a PR to fix the issues (some fixes belonged to the cri-tools repo, that are already merged and included in a patch release). All the fixes belong to the containerd/cri-tools repos, nothing to do here in runc: https://github.com/containerd/containerd/pull/10449.

Can someone please take a look at the moby issue? https://github.com/moby/moby/pull/47666

kolyshkin commented 2 months ago

Looking into https://github.com/moby/moby/pull/47666, as well as other dmz issues, I'm thinking maybe we should remove it entirely from runc-1.2?

rata commented 2 months ago

@kolyshkin are you sure that is dmz related? That moby PR is compiling with nodmz, there might be something on the say we disable it, but it felt like another issue given that it fails in the same way with and without the nodmz buildtag

kolyshkin commented 2 months ago

@kolyshkin are you sure that is dmz related? That moby PR is compiling with nodmz, there might be something on the say we disable it, but it felt like another issue given that it fails in the same way with and without the nodmz buildtag

Yeah, probably not. I will take a look.

rata commented 2 months ago

It was indeed something on the way runc_nodmz is disabled, work-around here: https://github.com/opencontainers/runc/pull/4345 (still need to fix cc_platform.mk).

I didn't manage to debug the failing tests now that docker compiles and need to leave now. Please someone else take a look :)

To use a patched runc, I used this moby PR to just compile my fork: https://github.com/moby/moby/pull/48161. Compilation works fine here, but the test fail. You can use something like that to try fixing the tests on the CI.

kolyshkin commented 2 months ago

I figured out the runc compile issue in moby; see https://github.com/moby/moby/pull/48160

apostasie commented 1 month ago

Hey folks.

Would it be possible to cut an RC3? Ideally that would allow closing https://github.com/containerd/nerdctl/pull/3153

Thanks!

AkihiroSuda commented 1 month ago

If somebody can take a look at incompatibility issues with Moby (https://github.com/moby/moby/pull/48336), that will be helpful for releasing the next RC (and GA)

rata commented 1 month ago

@AkihiroSuda I can't repro the issue locally (even without apparmor=0 in the kernel cmdline), I created a VM in Azure with a stock ubuntu (to see if there was something in that setup), but all test seem to pass just fine. I've tested CI without apparmor, etc, no differences (I'll update the moby PR with more details). @kolyshkin has been testing several things also and he can't repro either.

The issues in CI seem real to me, its' 100% reproducible that the new runc causes failures and the old doesn't. I guess there is something in the moby CI setup that we don't have in the other envs we are testing this.

@AkihiroSuda Can you have a look, please? @thaJeztah can you have a look too, pretty please?

AkihiroSuda commented 1 month ago

f2f16213e174fb63e931fe0546bbbad1d9bbed6f init: close internal fds before execve seems closing stdout too earlier

rata commented 1 month ago

Okay, I think I understand now the issues with moby: https://github.com/opencontainers/runc/issues/4384#issuecomment-2318191479. They are on moby, though, and not runc. @thaJeztah it would be great if you can take a look though, as it is quite moby related.

IMHO we can tag a new rc now. @AkihiroSuda @kolyshkin @cyphar @lifubang @thaJeztah (or any other maintainer reading this) what do you think?

lifubang commented 1 month ago

IMHO we can tag a new rc now.

I agree, if there is no begin, I'll open the release PR this weekend.

cyphar commented 1 month ago

@lifubang I'll do the release this time.

AkihiroSuda commented 3 weeks ago

Tried to run nerdctl tests with runc v1.2.0-rc.3, but something seems hanging on Ubuntu 20.04 (cgroup v1):

lifubang commented 1 week ago

4408

rata commented 5 days ago

@lifubang thanks! IMHO, we can cut rc4 when @cyphar fixes that issue

cyphar commented 5 days ago

I'll send a patch for it later today. (This will be our first logging output in filepath-securejoin, I guess I'll just use logrus...)