Skip to content

Refix COPY file . after WORKDIR (now always created)#28514

Merged
duglin merged 1 commit intomoby:masterfrom
microsoft:jjh/workdir
Nov 28, 2016
Merged

Refix COPY file . after WORKDIR (now always created)#28514
duglin merged 1 commit intomoby:masterfrom
microsoft:jjh/workdir

Conversation

@lowenna
Copy link
Copy Markdown
Member

@lowenna lowenna commented Nov 16, 2016

Signed-off-by: John Howard [email protected]

Fixes #27545 (again). @duglin @thaJeztah @vieux @cpuguy83

The fix for the above issue was in #27884, but reverted in #28505 as doing a mount/unmount for each container create is prohibitively expensive in terms of performance (as discovered by our performance team). Instead, this extends the interface from the builder back into the daemon so that the mount/unmount in container creation is done (on Windows) in the WORKDIR processing itself. The overall solution should still be in 1.13.

Edit: From comments below. The Linux behaviour has been updated to mirror the new Windows behaviour - WORKDIR in the builder always calls back into the daemon to create the directory rather than deferring it to the next statement.

@swernli @jstarks FYI.

@thaJeztah
Copy link
Copy Markdown
Member

#28505 was merged, so this can be rebased

@thaJeztah
Copy link
Copy Markdown
Member

@cpuguy83 @vieux up to you if it should be added to 1.13

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 17, 2016

Rebased

@thaJeztah
Copy link
Copy Markdown
Member

@jhowardmsft grmbl, needs another one already 😢

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 17, 2016

Rebased again...

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 18, 2016

@jhowardmsft I'm not sure I fully understand the issue so let me ask this... right now someone can do docker run --workdir foo ... and if foo doesn't exist it'll create it. This PR doesn't change that behavior, nor should it, so I'm wondering if the performance issue you're referring to would be seen, and an issue, in this case?

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 18, 2016

@duglin The performance issue is that with the old fix, every single docker run (which is really a create then a start) calls an extra mount/unmount regardless to setup the working directory in the create. While on Linux, that is a relatively cheap operation (very cheap); on Windows, to mount/unmount the scratchspace and initialize it added (I can't recall the exact figure without going back to email) something IRO 100+ms. That was an unacceptable performance regression in their opinion when everyone is working extremely hard to do everything possible to reduce container start times on Windows. Hence why this alternate fix only performs the mount/unmount in the WORKDIR builder call itself, rather than relying on it being done in a subsequent operation. Does that make sense?

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 18, 2016

ok I think I get it - let me just confirm.... the mount/unmount you're referring to only happens when the "working dir" isn't there in the image. So, in my previous comment when I talked about how specifying -w on docker run will still expose the performance hit there isn't much you can do about it - but in the case of the build's WORKDIR you can. Do I have that right?

If so, then this looks ok. One question I have, and its less for you and more for @tiborvass, would it make sense to have the build's WORKDIR logic do a mkdir even for Linux? This would then make the Windows and Linux flows the same. It might look odd to have different results between the two worlds.

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 18, 2016

@duglin - yes, you've got it 👍

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 18, 2016

I suspect @jhowardmsft wants this ASAP so I'll:
LGTM
for now and we can do a follow-on PR if we want to make Linux look the same as Windows.

@lowenna lowenna added this to the 1.13.0 milestone Nov 18, 2016
@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 21, 2016

@tiborvass Any chance of looking at this. Thanks 😄

Comment thread builder/dockerfile/dispatchers.go Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this was this way before, but should probably just be comment := "WORKDIR " + b.runConfig.WorkingDir

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in the forthcoming push with the Linux updates.

Comment thread daemon/workdir.go Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return container.SetupWorkingDirectory(0, 0)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will be fixed in the forthcoming update. But I need some more work here to support Linux anyway for the UID/GID mapping calls for UserNS

@tiborvass
Copy link
Copy Markdown
Contributor

@jhowardmsft these are just small nits, otherwise LGTM

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 22, 2016

@tiborvass any thoughts on this comment: #28514 (comment) ?

@tiborvass
Copy link
Copy Markdown
Contributor

@duglin From a code perspective it's better to mutualize as much as possible between windows and linux, so I would say yes I'm in favor. However is there anything that could break existing users? I couldn't think of anything.

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 22, 2016

I can't think of anything either and I like the consistency of it.

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 22, 2016

OK, I'll make the Linux change too.

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 22, 2016

@jhowardmsft thanks!

@lowenna lowenna changed the title Windows: Refix COPY file . after WORKDIR Refix COPY file . after WORKDIR (now always created) Nov 22, 2016
@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 22, 2016

@duglin @tiborvass Updated to matching behaviour on Linux and Windows, and fixed the nits from the previous review.

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 22, 2016

LGTM if janky is happy

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 22, 2016

Hmmm. TestCommitChange fails (doesn't run on Windows). Investigating....

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 22, 2016

@duglin. Fixed. The update to the previous commit is to not call back into the daemon if b.disableCommit is set - it was causing the daemon to panic. In the process, I've also ported TestCommitChange to Windows to verify it passes there too (that was the test which was failing on Linux) before the latest update.

Comment thread builder/dockerfile/dispatchers_test.go Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this test removed?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the previous commit, I skipped the test on Windows as the new path sent us calling through the backend into the daemon which wasn't setup in unit tests. Of course, with the latest fix described above, now that we only callback if the disableCommit flag isn't set, the test can be fully re-instated. So it'll be back in for the next update coming shortly.

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 23, 2016

looks good, just one question

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 23, 2016

Updated to re-instate the unit test after comment from @duglin

@lowenna
Copy link
Copy Markdown
Member Author

lowenna commented Nov 28, 2016

@duglin Still looks good? Could you give a final LGTM if so. Thanks. @tiborvass You OK with this too?

@duglin
Copy link
Copy Markdown
Contributor

duglin commented Nov 28, 2016

yup - still LGTM !

@tiborvass
Copy link
Copy Markdown
Contributor

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Inconsistent Dockerfile behavior between Windows Containers and Linux

7 participants