Low-hanging Windows fruit#1314
Conversation
|
Test results indicate that I can't simply revert 9290c15, as the containerd instance used in testing does not include the necessary shim binary |
95091bf to
6c556ad
Compare
|
I removed the reversion of 9290c15, until I have time to look into it further. I still think it's the correct choice, but it's a bit annoying that containerd doesn't check for the existence of the shim before using it as the default runtime, when it has non-shim runtimes available. |
|
containerd-shim-runc-v2 should be added here: Line 145 in f7cf482 |
e454e2d to
fb8833e
Compare
|
Regarding 9dca2db, I've just retriggered a conversation in containerd/containerd#2366 for this use-case, so it's possible in the future we could revert this change, if they decide they do want to support the target parameter of |
|
|
||
| func newContainerd(cdAddress string) (*containerd.Client, error) { | ||
| return containerd.New(cdAddress, containerd.WithTimeout(60*time.Second), containerd.WithDefaultRuntime("io.containerd.runtime.v1.linux")) | ||
| return containerd.New(cdAddress, containerd.WithTimeout(60*time.Second)) |
There was a problem hiding this comment.
This was needed in linux to support older containerd daemons that are not EOL yet.
There was a problem hiding this comment.
That's odd, because it was only added when containerd 1.3 was vendor'd. Previous containerd has this as the default value already, from my reading, and containerd changed the default to the runtime v2 shim in 1.3.
There was a problem hiding this comment.
@TBBle: When you get back to this, see if the problem is that the default is being controlled by the vendored part, not the daemon.
There was a problem hiding this comment.
Containerd client(vendored) unfortunately can't do detection of the supported shims (although the client should always be backward compatible based on docs). So it will default to shim2 and fail on older daemons because they don't have any shim2 binary.
There was a problem hiding this comment.
Note that this isn't a problem for windows though as none of this works for old containerd in windows anyway.
There was a problem hiding this comment.
That of course means it's not low-hanging fruit, so unless I find time to really hammer this out (including working out how to get the unit tests to catch this in future), I'll pull these two changes out of the PR.
There was a problem hiding this comment.
@tonistiigi : According to #1176, buildkit dropped support for containerd older than 1.3 already. Or am I misreading that?
There was a problem hiding this comment.
Yes and no. It is true #1176 depends on 1.3 but it still works with older daemons while being less efficient on releasing data in some cases. This is different than getting fatal "binary not found" error on every build.
There was a problem hiding this comment.
I've pulled this commit and the previous one (pulling the new containerd Linux V2 runtime into the travis build), I'll come back to this in a new pull request later.
I plan to introduce a command-line option to select containerd runtime, with legacy runc runtime as default on non-Windows (matching containerd 1.2), and hcsshim runtime as default on Windows (matching containerd 1.3).
I'll also try and reinstate the Containerd 1.2 unit tests in the Travis build, so I or someone else doesn't fall into this gap again.
There was a problem hiding this comment.
@tonistiigi Are you sure that the current master works with containerd 1.2? I tried enabling the containerd 1.2 unit tests (#1348), and a fair few of them died trying to call AddResource against containerd, which was added in 1.3.0.
It looks like anything hitting func (s *sourceOp) Exec for the containerimage source will end up in func (cm *cacheManager) GetByBlob, which calls LeaseManager.AddResource and hence fails against containerd 1.2.
It's very possible I'm overlooking something obvious, but I do not currently see any path that can bypass those calls when the API is not present.
Is there just a class of tests/features that are not valid with containerd 1.2?
fb8833e to
f16d33b
Compare
This reverts commit c4f0305. containerd 1.2 is still supported, per discussion at moby#1314 (comment) Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
The same function used to support Unix sockets automatically supports Named Pipes on Windows. This makes the default configuration option for the daemon address work correctly on Windows. Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Wrapping a `nil` error produces `nil`, which causes the calling code to see success, and continue on with a default-created WorkerOpt, which causes segfaults later. Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
This makes this code successfully discover the Windows Runtime V2 (hcsshim-based) plugin now that the Windows Runtime V1 (runhcs-based) plugin has been removed upstream. Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
The check for running as a non-admin euid() doesn't work on Windows, always returning -1. For now, treat -1 as "Probably root", and let the failures happen later. Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Non-packaged execution will need this to be overridden anyway, and it avoids a surprise "Drop state data into the current working directory" event. Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
f16d33b to
b9cf317
Compare
|
Compared to the original PR, I've pulled the two changes which turned out to not be low-hanging fruit for later reworking in different PRs. Need to better-manage the choice of Runtime plugin for the containerd worker
Handle deficiencies in the containerd
|
This reverts commit c4f0305. containerd 1.2 is still supported, per discussion at moby#1314 (comment) Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
This reverts commit c4f0305. containerd 1.2 is still supported, per discussion at moby#1314 (comment) Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
This reverts commit c4f0305. containerd 1.2 is still supported, per discussion at moby#1314 (comment) Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
This reverts commit c4f0305. containerd 1.2 is still supported, per discussion at moby#1314 (comment) Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Per moby#1314 (comment) BuildKit should still function with containerd 1.2 daemons that do not have this API, but less efficiently. However, a couple of hundred tests fail on CI when they hit this, so just skip them for now. Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
Per moby#1314 (comment) BuildKit should still function with containerd 1.2 daemons that do not have this API, but less efficiently. However, a couple of hundred tests fail on CI when they hit this, so just skip them for now. WIP because this doesn't work, see the TODO in Run in run.go. Signed-off-by: Paul "TBBle" Hampson <Paul.Hampson@Pobox.com>
A bunch of small changes that fix blocking issue for supporting Buildkit on Windows against containerd.
This doesn't result in working Windows support, but the remaining areas of support are harder-to-solve, relating (so far) to either container spec generation, various aspects of network namespace handling, or various LLB commands that refuse to work if they cannot do user id mapping.
This is to advance #616, but does not complete it.