Change:
<ins> # Copyright 2017 The Kubernetes Authors. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Build the hyperkube base image. This image is used to build the hyperkube image. # # Usage: #   [ARCH=amd64] [REGISTRY="gcr.io/google-containers"] make (build|push) REGISTRY?=gcr.io/google-containers IMAGE?=debian-hyperkube-base TAG=0.1 ARCH?=amd64 CACHEBUST?=1 BASEIMAGE=gcr.io/google-containers/debian-base-$(ARCH):0.1 CNI_RELEASE=0799f5732f2a11b329d9e3d51b9c8f2e3759f2ff TEMP_DIR:=$(shell mktemp -d) CNI_TARBALL=cni-$(ARCH)-$(CNI_RELEASE).tar.gz .PHONY: all build push clean all: push cni-tars/$(CNI_TARBALL): mkdir -p cni-tars/ cd cni-tars/ && curl -sSLO --retry 5 https://storage.googleapis.com/kubernetes-release/network-plugins/${CNI_TARBALL} clean: rm -rf cni-tars/ build: cni-tars/$(CNI_TARBALL) cp Dockerfile $(TEMP_DIR) cd $(TEMP_DIR) && sed -i "s|BASEIMAGE|$(BASEIMAGE)|g" Dockerfile ifeq ($(CACHEBUST),1) cd ${TEMP_DIR} && sed -i.back "s|CACHEBUST|$(shell uuidgen)|g" Dockerfile endif mkdir -p ${TEMP_DIR}/cni-bin tar -xz -C ${TEMP_DIR}/cni-bin -f "cni-tars/${CNI_TARBALL}" docker build --pull -t $(REGISTRY)/$(IMAGE)-$(ARCH):$(TAG) $(TEMP_DIR) rm -rf $(TEMP_DIR) push: build gcloud docker -- push $(REGISTRY)/$(IMAGE)-$(ARCH):$(TAG) </ins>

Discussion:
I'm pretty sure that building the hyperkube images takes longer than building kubernetes itself now. At least a large part of this seems to be that we download and install ~172 extra debian packages several times (once for each arch). <details</detailsNot sure how to improve this - maybe better caching? Do we actually want to install these extra packages? Should we use a better base image than ? cc
cc (not really sure who "owns" hyperkube, if anyone)
The hyperkube binary is one thing. I think the image ends up being big as we drag in so much stuff. I wasn't involved in creating the docker image so I can't comment. Ideally this thing would be slim and would have minimal external dependencies. Fixing this starts with mapping why we have each of those deps imported.
I actually have written a such patch in my local env, but I never uploaded. It removed the docker and docker-multinode-specific stuff and all the unused deps. Also, we will come one step closer once is in. Should I submit the patch so you can take a look at it?
sure!
This needs to be triaged as a release-blocker or not for 1.5
punting to v1.6.
The main problem here is that we're installing huge packages for supporting some volume types: git nfs-common glusterfs-client cifs-utils With containerized volume mounters we'll get rid of that.
When it comes to local rebuilding, should help here. As I've already noted in the PR, maybe we should make CACHEBUST=0 the default for all hack/dev- scripts. This would at least ease development and testing.
can this be closed? or moved to 1.7?
should this be in v1.7? is there an appropriate sig to own this?
cries nope, not v1.7. I'm still not sure who owns hyperkube.
Everyone and no one I suppose. Yeah, agree it's sad.
/sig release guess we're saying sig-release owns hyperkube under the general guise of "cutting bits" until/unless there is a better home for it
Yeah, hyperkube definitely belongs to sig-release as it hasn't been owned by a sig so far...