Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from Nov 28, 2016

Conversation

lowenna
Copy link
Member

@lowenna lowenna commented Nov 16, 2016

Signed-off-by: John Howard jhoward@microsoft.com

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
Member

#28505 was merged, so this can be rebased

@thaJeztah
Copy link
Member

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

@lowenna
Copy link
Member Author

lowenna commented Nov 17, 2016

Rebased

@thaJeztah
Copy link
Member

@jhowardmsft grmbl, needs another one already 😢

@lowenna
Copy link
Member Author

lowenna commented Nov 17, 2016

Rebased again...

@duglin
Copy link
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
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
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
Member Author

lowenna commented Nov 18, 2016

@duglin - yes, you've got it 👍

@duglin
Copy link
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
Member Author

lowenna commented Nov 21, 2016

@tiborvass Any chance of looking at this. Thanks 😄

@@ -279,12 +280,31 @@ func workdir(b *Builder, args []string, attributes map[string]bool, original str
return err
}

// NOTE: You won't find the "mkdir" for the directory in here. Rather we
comment := fmt.Sprintf("WORKDIR %v", b.runConfig.WorkingDir)
Copy link
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
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.

return err
}
defer daemon.Unmount(container)
if err := container.SetupWorkingDirectory(0, 0); err != nil {
Copy link
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
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
Contributor

@jhowardmsft these are just small nits, otherwise LGTM

@duglin
Copy link
Contributor

duglin commented Nov 22, 2016

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

@tiborvass
Copy link
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
Contributor

duglin commented Nov 22, 2016

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

@lowenna
Copy link
Member Author

lowenna commented Nov 22, 2016

OK, I'll make the Linux change too.

@duglin
Copy link
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
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
Contributor

duglin commented Nov 22, 2016

LGTM if janky is happy

@lowenna
Copy link
Member Author

lowenna commented Nov 22, 2016

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

@lowenna
Copy link
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.

@@ -256,27 +256,6 @@ func TestOnbuild(t *testing.T) {
}
}

func TestWorkdir(t *testing.T) {
Copy link
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
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
Contributor

duglin commented Nov 23, 2016

looks good, just one question

Signed-off-by: John Howard <jhoward@microsoft.com>
@lowenna
Copy link
Member Author

lowenna commented Nov 23, 2016

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

@lowenna
Copy link
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
Contributor

duglin commented Nov 28, 2016

yup - still LGTM !

@tiborvass
Copy link
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