A benchmark with go1.16 on amd64 resulted in an overall maximum memory
usage of 15GiB. This means we now lower the `KUBE_PARALLEL_BUILD_MEMORY`
to `20` to still have some room left.
The benchmark has been done with the following `Dockerfile`:
```dockerfile
FROM k8s.gcr.io/build-image/kube-cross:v1.16.0-1
RUN apt-get update && apt-get install -y time
WORKDIR /go/src/k8s.io/kubernetes
RUN git clone https://github.com/kubernetes/kubernetes
ENV KUBE_PARALLEL_BUILD_MEMORY=0
RUN /usr/bin/time -v make -C kubernetes cross-in-a-container
```
The value of interest from the output:
```
Maximum resident set size (kbytes): 1847108
```
The RSS is not the only value we have to consider. During the runtime I
measured the usage of the cached memory, which gets peaks up to 15GiB.
Test machine specs:
- CPU: 2 x Intel Scalable Gold 5120 28-Core Processor @ 2.2GHz
- RAM: 384GB
- Disk: 1 x 3.8TB NVME
- OS: Debian 10 (buster)
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Since this invalid Semantic Version messages redirecting to stdout
will be captured by line 790 at hack/lib/golang.sh:
`goldflags="${GOLDFLAGS=-s -w -buildid=} $(kube::version::ldflags)"`
This happens when only no valid tag exists in repo
Currently target CC can only be set if the host platform
is linux/amd64 . If target is already set in the environment
it is always safe to use it and enable cgo.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
The amount of memory required to build binaries in parallel is right now
set to 40GiB. We now make this variable to be able to build artifacts in
parallel even with a lower amount of memory.
This enables SIG Release to speed-up the build time drastically in
Google Cloud Build (GCB).
Signed-off-by: Sascha Grunert <sgrunert@suse.com>
* switched one spot to use kube::logging
* make kube::util::find-binary return an error when it doesn't find
anything so that hack scripts fail fast instead of with '' binary not
found errors.
* this required deleting some genfeddoc stuff. the binary no longer
exists in k/k repo since we removed federation/, and I don't see it
in https://github.com/kubernetes-sigs/kubefed/ either. I'm assuming
that it's gone for good now.
If a bearer token is present in a request, the exec credential plugin should accept that as the chosen method of authentication. Judging by an [earlier comment in exec.go](c18bc7e9f7/staging/src/k8s.io/client-go/plugin/pkg/client/auth/exec/exec.go (L217)), this was already intended. This would however not work since UpdateTransportConfig would set the GetCert callback which would then get called by the transport, triggering the exec plugin action even with a token present in the request. See linked issue for further details.
See #87369 for further details.
Signed-off-by: Anders Eknert <anders.eknert@bisnode.com>
