Block pulling Windows images on non-Windows daemons #29001

darstahl · 2016-11-30T21:59:16Z

This is an alternative solution to #28903

- What I did

Block pulling Windows images on Linux daemons.

- How I did it

If the listed OS of an image's config is Windows, but the current daemon platform is not Windows, fail to download the image.

- How to verify it

Pull microsoft/nanoserver on a Linux daemon. See test that checks this.

- Description for the changelog

Block pulling of Windows images on a non-windows daemon.

Signed-off-by: Darren Stahl darst@microsoft.com

/cc @jhowardmsft @jstarks

aaronlehmann · 2016-11-30T22:32:55Z

Instead of downloading the config before starting to download the layers (which will add a noticeable delay), how running p.config.DownloadManager.Download in a goroutine and aborting it by canceling the context if the config turns out to be incompatible?

darstahl · 2016-11-30T22:46:35Z

@aaronlehmann That can't be done on Windows, as some filenames in Linux images are not valid in NTFS resulting in a failure mid download. I'm not sure if it can be done in the Linux case, since the Linux daemon is not aware of foreign layers, the failure is occurring during download, rather than when attempting to run the resulting image. I'll try it on Linux pulling a Windows image, but even if it works, it would be diverging the handling between platforms.

aaronlehmann · 2016-11-30T23:18:43Z

If the problem is foreign layers, those are easy to detect before downloading the layers. We could abort the pull if the platform is Linux and any of the descriptors in the manifest has a media type indiciating a foreign layer. That wouldn't require downloading the image config before starting the layer downloads.

darstahl · 2016-12-01T00:09:08Z

The problem isn't only the foreign layers. It just happens that all Windows images have at least one foreign layer, since Windows images must be based off one of the two base images, both of which contain foreign layers. Downloading both the image config and the layers at the same time is a race between which would fail first, and produce a different error depending on which download wins.

I initially avoided this solution (reading image config before layer download), due to the expected performance impact, and did what you are suggesting (checking the layer descriptor before attempting to download a foreign layer). See #28903. It was suggested there to fail earlier by doing the same checks that Windows already does on Linux. Both of these solve the same problem, but have different drawbacks.

Edit: Just to be clear, I don't have a huge preference for this solution vs #28903, they both (almost) solve the same problem of Linux users being confused when attempting to download a Windows based image.

thaJeztah · 2016-12-12T14:46:19Z

ping @aaronlehmann @stevvooe any way to get this PR, or #28903, moving again?

aaronlehmann · 2016-12-12T18:35:06Z

My preference here is for something like this (untested, only meant to illustrate the idea):

https://github.com/aaronlehmann/docker/tree/block-wrong-os

This runs the download manager in a separate goroutine, so the pullSchema2 function can abort the pull as soon as the config is downloaded, if that config specifies the wrong platform. This doesn't require fully downloading the config before starting the layer downloads on Linux.

The NTFS issue wouldn't be a factor because Windows daemons always download and check the config first. The foreign layer issue on Linux could be solved by adding a check for foreign layers in the loop over mfst.Layers at the top of pullSchema2, before any of these downloads start. This will let us fail even faster than when trying to download a layer.

AkihiroSuda · 2017-01-19T07:57:20Z

@darrenstahlmsft

WDYT about @aaronlehmann 's comment?

LK4D4 · 2017-01-27T20:26:32Z

ping @darrenstahlmsft

thaJeztah · 2017-01-30T14:55:35Z

also ping @stevvooe PTAL

darstahl · 2017-01-31T22:23:02Z

Updated to be similar to the commit by @aaronlehmann except that in the case of an error downloading the layer, the config download is not cancelled so that the resulting error message takes priority over the layer download failure.

I think that lets us remove the serialization of the Windows config as well. I've left that for a follow-up PR though.

aaronlehmann · 2017-02-01T10:38:23Z

I see that TestEventsPluginOps timed out on both janky and experimental, so I suspect this is causing some problem with pulling plugins.

aaronlehmann · 2017-02-01T10:44:43Z

integration-cli/docker_cli_pull_test.go

+// Regression test for https://github.com/docker/docker/issues/28892
+func (s *DockerSuite) TestPullWindowsImageFailsOnLinux(c *check.C) {
+	testRequires(c, DaemonIsLinux, Network)
+	_, _, err := dockerCmdWithError("pull", "microsoft/nanoserver")


Ideally we'd serve a minimal Windows image from a local registry instead of depending on Docker Hub. I just filed #30626 about something similar.

This is probably outside the scope of this PR though. I think the download-frozen-image-v2.sh script in the Dockerfile is capable of downloading the image at docker build time, but it would take some extra scripting work to load this image into a local registry without the use of docker pull / docker push.

It would be even better to use some plain "scratch" image with Windows config, instead of downloading 333MB nanoserver image.

@AkihiroSuda There is no such thing. Nanoserver is the smallest Windows image available.

aaronlehmann · 2017-02-01T10:51:04Z

distribution/pull_v2.go

+	select {
+	case <-downloadsDone:
+	case err = <-errChan:
+		cancel()


Instead of calling cancel here, lets add defer cancel() after the call to WithCancel. We should be making sure to always cancel the context when returning anyway, as this releases the resources associated with it.

aaronlehmann · 2017-02-01T10:51:58Z

distribution/pull_v2.go

@@ -552,6 +553,7 @@ func (p *v2Puller) pullSchema2(ctx context.Context, ref reference.Named, mfst *s
 		configJSON       []byte        // raw serialized image config
 		downloadedRootFS *image.RootFS // rootFS from registered layers
 		configRootFS     *image.RootFS // rootFS from configuration
+		release          func()        // relase resources from rootFS download


typo: "relase"

aaronlehmann · 2017-02-01T10:54:59Z

This looks like the right approach to me. Moving to code review.

Let me know if I can be of any help in tracking down the plugin test issue. Also pinging @dmcgowan who converted plugins to use the pull_v2 code.

darstahl · 2017-02-02T01:53:43Z

Fixed the plugin error, but now it's failing on TestDaemonNoSpaceLeftOnDeviceError, which still seems related. I'll take a look at that tomorrow.

aaronlehmann · 2017-02-02T11:24:04Z

distribution/pull_v2.go

@@ -533,7 +533,8 @@ func (p *v2Puller) pullSchema2(ctx context.Context, ref reference.Named, mfst *s
 	}

 	configChan := make(chan []byte, 1)
-	errChan := make(chan error, 1)
+	errChan := make(chan error, 2)
+	downloadsDone := make(chan error, 1)


This can be downloadsDone := make(chan struct{}), since no data is ever conveyed over it.

Huh, I was certain I'd made it a struct{} chan in the first place, oops... Fixed.

aaronlehmann · 2017-02-02T11:34:17Z

Ah, I think I see the problem that is causing TestDaemonNoSpaceLeftOnDeviceError to hang.

receiveConfig may get an error from the layer downloads on errChan, and afterwards the select below receiveConfig will wait for activity on downloadsDone or errChan, but neither will happen, because the downloading goroutine has already returned and its message on errChan was swallowed up by receiveConfig.

One way to fix this would be to use separate error channels for layer downloads and the config retrieval.

Signed-off-by: Darren Stahl <darst@microsoft.com>

darstahl · 2017-02-02T21:19:01Z

Good catch @aaronlehmann. Fixed the hang.

aaronlehmann · 2017-02-02T22:09:06Z

LGTM

AkihiroSuda · 2017-02-03T01:08:01Z

distribution/config.go

 	if runtime.GOOS == "windows" && unmarshalledConfig.OS == "linux" {
 		return nil, fmt.Errorf("image operating system %q cannot be used on this platform", unmarshalledConfig.OS)
+	} else if runtime.GOOS != "windows" && unmarshalledConfig.OS == "windows" {


why not just check runtime.GOOS != unmarshelledConfig.OS here?
(Although we can support runtime.GOOS == "freebsd" && unmarshalledConfig.OS == "linux" in future 😄)

why not just check runtime.GOOS != unmarshelledConfig.OS here?

I'm afraid this might have some unintended consequences. For example, what if there are images out there built with nonstandard tools that don't set the OS field? For now I think it's best to explicitly check for incompatible configurations.

runcom · 2017-02-16T17:49:05Z

LGTM ping @anusha-ragunathan @vdemeester

vdemeester

LGTM 🐸

GordonTheTurtle added the status/0-triage label Nov 30, 2016

darstahl mentioned this pull request Nov 30, 2016

Fail to pull foreign layers when not supported #28903

Closed

wking mentioned this pull request Dec 1, 2016

Clarify when non-distributable layer policies should be enforced opencontainers/image-spec#475

Closed

thaJeztah added status/1-design-review and removed status/0-triage labels Dec 12, 2016

darstahl force-pushed the WindowsOnLinux branch from b6d0e66 to 40ca3c9 Compare January 31, 2017 22:18

aaronlehmann reviewed Feb 1, 2017

View reviewed changes

aaronlehmann added status/2-code-review and removed status/1-design-review labels Feb 1, 2017

darstahl force-pushed the WindowsOnLinux branch from 40ca3c9 to f3cfb73 Compare February 1, 2017 23:17

aaronlehmann reviewed Feb 2, 2017

View reviewed changes

darstahl force-pushed the WindowsOnLinux branch 2 times, most recently from 480c8b1 to 0755ed4 Compare February 2, 2017 19:06

Block Windows images on Linux

d553040

Signed-off-by: Darren Stahl <darst@microsoft.com>

darstahl force-pushed the WindowsOnLinux branch from 0755ed4 to d553040 Compare February 2, 2017 19:08

AkihiroSuda reviewed Feb 3, 2017

View reviewed changes

GordonTheTurtle assigned anusha-ragunathan Feb 10, 2017

runcom added status/4-merge and removed status/2-code-review labels Feb 16, 2017

vdemeester approved these changes Feb 16, 2017

View reviewed changes

vdemeester merged commit c31f73a into moby:master Feb 16, 2017

GordonTheTurtle added this to the 1.14.0 milestone Feb 16, 2017

thaJeztah added the impact/changelog label Feb 21, 2017

darstahl deleted the WindowsOnLinux branch April 3, 2017 20:53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Block pulling Windows images on non-Windows daemons #29001

Block pulling Windows images on non-Windows daemons #29001

darstahl commented Nov 30, 2016 •

edited

Loading

aaronlehmann commented Nov 30, 2016

darstahl commented Nov 30, 2016 •

edited

Loading

aaronlehmann commented Nov 30, 2016

darstahl commented Dec 1, 2016 •

edited

Loading

thaJeztah commented Dec 12, 2016

aaronlehmann commented Dec 12, 2016

AkihiroSuda commented Jan 19, 2017

LK4D4 commented Jan 27, 2017

thaJeztah commented Jan 30, 2017

darstahl commented Jan 31, 2017

aaronlehmann commented Feb 1, 2017

aaronlehmann Feb 1, 2017

AkihiroSuda Feb 3, 2017

lowenna Feb 3, 2017

aaronlehmann Feb 1, 2017

aaronlehmann Feb 1, 2017

aaronlehmann commented Feb 1, 2017

darstahl commented Feb 2, 2017

aaronlehmann Feb 2, 2017

darstahl Feb 2, 2017

aaronlehmann commented Feb 2, 2017

darstahl commented Feb 2, 2017

aaronlehmann commented Feb 2, 2017

AkihiroSuda Feb 3, 2017

aaronlehmann Feb 3, 2017

AkihiroSuda Feb 3, 2017

runcom commented Feb 16, 2017

vdemeester left a comment

Block pulling Windows images on non-Windows daemons #29001

Block pulling Windows images on non-Windows daemons #29001

Conversation

darstahl commented Nov 30, 2016 • edited Loading

aaronlehmann commented Nov 30, 2016

darstahl commented Nov 30, 2016 • edited Loading

aaronlehmann commented Nov 30, 2016

darstahl commented Dec 1, 2016 • edited Loading

thaJeztah commented Dec 12, 2016

aaronlehmann commented Dec 12, 2016

AkihiroSuda commented Jan 19, 2017

LK4D4 commented Jan 27, 2017

thaJeztah commented Jan 30, 2017

darstahl commented Jan 31, 2017

aaronlehmann commented Feb 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aaronlehmann commented Feb 1, 2017

darstahl commented Feb 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aaronlehmann commented Feb 2, 2017

darstahl commented Feb 2, 2017

aaronlehmann commented Feb 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

runcom commented Feb 16, 2017

vdemeester left a comment

Choose a reason for hiding this comment

darstahl commented Nov 30, 2016 •

edited

Loading

darstahl commented Nov 30, 2016 •

edited

Loading

darstahl commented Dec 1, 2016 •

edited

Loading