Conversation
|
Looks like maybe I broke Jenkins. I'll debug tomorrow. |
|
Build finished. 3357 tests run, 14 skipped, 0 failed. |
|
Build finished. |
|
Build finished. 330 tests run, 329 skipped, 0 failed. |
|
/subscribe |
build/common.sh
Outdated
There was a problem hiding this comment.
I guess boot2docker should be removed from here...
There was a problem hiding this comment.
I removed all references to boot2docker.
|
I think it's worthy a release note since it breaks boot2docker |
|
With respect to release note -- this will have zero impact on end users. It won't impact the release at all. I think that we want to announce it widely to everyone working on kubernetes itself but I don't think it needs a release note. |
|
release notes are for things that affect end users, not developers, so I think release-note-none and a thread on kubernetes-dev are the way to go. |
|
this is neat :) |
|
@thockin -- wanted to make sure you saw this. |
|
Moderately impactful for folks who don't run the VMs shipped by Docker, but it's not a deal breaker (it's just more config to make the default paths work, which most people do). |
|
I'm running docker for mac (d4m) and I do not see a file sharing tab. Do you have a sample screenshot of what that looks like? Secondarily: |
|
Just tested this. Thanks for the cleanup @jbeda! |
build/common.sh
Outdated
There was a problem hiding this comment.
Can't we just use the local _output/local/go/pkg dir to cache incremental builds, and get rid of the data container entirely? We're using docker as a way to get a hermetic, reproducable build with known-good tools. The source itself is in my local dir. The data container is a leftover from a bygone era.
There was a problem hiding this comment.
Not really -- subtleties here:
- The way that host directories are shared into the VM and bind mounted into the container is super slow through VirtualBox. This is one of the big things that comes from Docker for Mac
- Not all of the intermediate files are under _output. The fact that we need to recompile the standard libraries (and if we don't cache the world gets rebuilt) means we need to map /usr/local/go/pkg/linux_amd64_cgo too.
If we knew that bind mounts would be fast enough, perhaps we could make it work. But they are really slow with VirtualBox.
There was a problem hiding this comment.
Do you know how much sympathy I have for "I want to build from a mac" ? :)
But I am a little confused, I thought the data container only carries /go/src/k8s.io/kubernetes/_output anyway - nothing to do with /usr/local/go (excellent point, though). Given that you assert that bind mounts are slow, we still need to copy the source code into a container, or the build will be v.slow (only for Mac people, who should be used to that by now anyway).
There was a problem hiding this comment.
Part of this change does away with the "tar up source and copy it over" and instead moves to a "bind mount source readonly". This may slow down the virtualbox build. I need to test that. I don't remember if the slow part was read/write or just pure read path. I'll test that out.
This change also makes sure that the /usr/local/go stuff is cached between runs. That is critical for getting builds to be fast and incremental.
There was a problem hiding this comment.
Ahh. Yes, well, it would be GREAT if we didn't need the data container. Eventually, maybe?
- Remove support for boot2docker. - Remove support for "copying" binaries back from remote docker engine. I doubt anyone is using this and it slows down other parts of the system.
* No longer tar up sources but instead use a read-only host mount. * Make sure /usr/local/go/pkg/*_cgo is saved/cached across runs
|
Thanks for blocking. part 1 of 3 is in, part 2 is in queue. Part 3 has had partial review, but I will try to get it into queue tomorrow. |
|
@jbeda PR needs rebase |
|
GCE e2e build/test passed for commit d8ab401. |
|
@thockin -- are you ready for me to pick this up again and rehabilitate it? |
|
go for it. I have no pending build changes at the moment. On Mon, Aug 8, 2016 at 9:25 AM, Joe Beda notifications@github.com wrote:
|
|
cc @spxtr |
|
@jbeda Needs a rebase. Would be great to have faster dockerized builds... |
|
Not much to add. I'll give it a run after the rebase. Reviewed 5 of 7 files at r1, 7 of 7 files at r2. build/common.sh, line 248 [r2] (raw file):
maybe cluster/mesos/docker/util.sh, line 81 [r2] (raw file):
This doesn't seem right. I know you didn't change it, but I saw it out the corner of my eye. Is this function even used? Comments from Reviewable |
Automatic merge from submit-queue Speed up dockerized builds This PR speeds up dockerized builds. First, we make sure that we are as incremental as possible. The bigger change is that now we use rsync to move sources into the container and get data back out. To do yet: * [x] Add a random password to rsync. This is 128bit MD4, but it is better than nothing. * [x] Lock down rsync to only come from the host. * [x] Deal with remote docker engines -- this should be necessary for docker-machine on the mac. * [x] Allow users to specify the port for the rsync daemon. Perhaps randomize this or let docker pick an ephemeral port and detect the port? * [x] Copy back generated files so that users can check them in. This is done for `zz_generated.*` files generated by `make generated_files` * [x] This should include generated proto files so that we can remove the hack-o-rama that is `hack/hack/update-*-dockerized.sh` * [x] Start "versioning" the build container and the data container so that the CI system doesn't have to be manually kicked. * [x] Get some benchmarks to qualify how much faster. This replaces #28518 and is related to #30600. cc @thockin @spxtr @david-mcmahon @MHBauer Benchmarks by running `make clean ; sync ; time bash -xc 'time build/make-build-image.sh ; time sync ; time build/run.sh make ; time sync; time build/run.sh make'` on a GCE n1-standard-8 with PD-SSD. | setup | build image | sync | first build | sync | second build | total | |-------|-------------|----- |----------|------|--------------|------| | baseline | 0m11.420s | 0m0.812s | 7m2.353s | 0m42.380s | 7m8.381s | 15m5.348s | | this pr | 0m10.977s | 0m15.168s | 7m31.096s | 1m55.692s | 0m16.514s | 10m9.449s |
These changes make the assumption that host volume mounts work. With docker for Mac and docker-machine supporting them there are very few cases left where the build target is truly remote.
With that in mind:
If this passes the sniff test I'll send out a message to kubernetes-dev to let everyone know this is coming and make sure we aren't pulling the rug out from under anyone.
This change is