Bug 1467334 - stdlib pkg with cgo flag not found, Kubernetes build is slow
stdlib pkg with cgo flag not found, Kubernetes build is slow
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kubernetes (Show other bugs)
25
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan Chaloupka
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-03 08:26 EDT by Jan Pazdziora
Modified: 2017-07-11 03:29 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-07-03 09:05:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2017-07-03 08:26:48 EDT
Description of problem:

Building Kubernetes with make all, there is warning

+++ [0703 12:22:14] +++ Warning: stdlib pkg with cgo flag not found.
+++ [0703 12:22:14] +++ Warning: stdlib pkg cannot be rebuilt since /usr/lib/golang/pkg is not writable by test
+++ [0703 12:22:14] +++ Warning: Make /usr/lib/golang/pkg writable for test for a one-time stdlib install, Or
+++ [0703 12:22:14] +++ Warning: Rebuild stdlib using the command 'CGO_ENABLED=0 go install -a -installsuffix cgo std'
+++ [0703 12:22:14] +++ Falling back to go build, which is slower

and indeed, the build is slow and re-running make all takes the same time, it looks like previously built artefacts are not reused.

Version-Release number of selected component (if applicable):

golang-1.7.6-2.fc25.x86_64
golang-race-1.7.6-2.fc25.x86_64

How reproducible:

Deterministic.

Steps to Reproduce:
1. git clone https://github.com/kubernetes/kubernetes.git
2. cd kubernetes
3. make all
4. make all

Actual results:

$ make all
+++ [0703 12:22:13] Building the toolchain targets:
    k8s.io/kubernetes/hack/cmd/teststale
    k8s.io/kubernetes/vendor/github.com/jteeuwen/go-bindata/go-bindata
+++ [0703 12:22:13] Generating bindata:
    test/e2e/generated/gobindata_util.go
~/kubernetes ~/kubernetes/test/e2e/generated
~/kubernetes/test/e2e/generated
+++ [0703 12:22:14] Building go targets for linux/amd64:
    cmd/kube-proxy
    cmd/kube-apiserver
    cmd/kube-controller-manager
    cmd/cloud-controller-manager
    cmd/kubelet
    cmd/kubeadm
    cmd/hyperkube
    vendor/k8s.io/kube-aggregator
    vendor/k8s.io/apiextensions-apiserver
    plugin/cmd/kube-scheduler
    cmd/kubectl
    federation/cmd/kubefed
    cmd/gendocs
    cmd/genkubedocs
    cmd/genman
    cmd/genyaml
    cmd/mungedocs
    cmd/genswaggertypedocs
    cmd/linkcheck
    federation/cmd/genfeddocs
    vendor/github.com/onsi/ginkgo/ginkgo
    test/e2e/e2e.test
    cmd/kubemark
    vendor/github.com/onsi/ginkgo/ginkgo
    test/e2e_node/e2e_node.test
    cmd/gke-certificates-controller
+++ [0703 12:22:14] +++ Warning: stdlib pkg with cgo flag not found.
+++ [0703 12:22:14] +++ Warning: stdlib pkg cannot be rebuilt since /usr/lib/golang/pkg is not writable by test
+++ [0703 12:22:14] +++ Warning: Make /usr/lib/golang/pkg writable for test for a one-time stdlib install, Or
+++ [0703 12:22:14] +++ Warning: Rebuild stdlib using the command 'CGO_ENABLED=0 go install -a -installsuffix cgo std'
+++ [0703 12:22:14] +++ Falling back to go build, which is slower
    ************************
    ^^^ this takes many minutes

and the subsequent run takes the same time.

Expected results:

No complaint about that "stdlib pkg with cgo flag not found" and re-running make all takes few seconds.

Additional info:
Comment 1 Jan Chaloupka 2017-07-03 09:05:13 EDT
This is a warning message from Kubernetes build make script. Given the Kubernetes is built in Koji, there is no need to re-run the building process again.
Comment 2 Jan Pazdziora 2017-07-03 09:39:44 EDT
If we try to position Fedora as distribution which developers might want (and love) to use, we might want to make it easy for them to build stuff, even if that stuff is also packaged in Fedora.

Sources around Internet seem to suggest that that cgo flag might enable faster operation in a particular workload (building Kubernetes, in this case). Why can't that flag be enabled in the golang packaged by Fedora?
Comment 3 Jan Chaloupka 2017-07-03 10:32:41 EDT
Any developer building the Kubernetes will have to find a way how to build/re-build subcomponents the way it suits him the best. Including updating/editing the building scripts. It is a part of the learning curve.

I am open to improving the building process of Kubernetes in Fedora. I can even extend the %build section with additional comments with steps that help to speed up the building time. Jakub, WDYT?
Comment 4 Jakub Čajka 2017-07-11 03:29:46 EDT
@jchaloup Sure, why not. I would love to see some extensive docs/breakdown of kube's/openshift's build scripts(IIRC when I have checked for it I haven't seen anything like that in upstream, but it has been some time ago).

@jpazdziora: In Fedora stdlib/GC is built with CGO enabled on all supported platforms by CGO. And as jchaloup noted there is noway how intermediate file re-use would be usefull or even desirable in RPM build environment(withing kube it self). We do provide prebuilt stdlib to speed up builds and make them more reproducible.

More general shout out.

Do you know what kube build scripts actually trying to do, are doing(actual commands run)? How and why it is checking the stdlib(and what it assumes/expects)? It seems to be as quiet odd that it tries(?)/recommends to rebuild std with cgo disabled(isn't it by coincidence on ppc64?, there it would make sense, as CGO there is by default disabled and not there at all).

To be honest kube's build scripts seem to me as quiet opaque. Why isn't kube easily build-able with something plain and simple as "go install", "go build" or using some simple script(s) as GC itself or some standard well known(definitively not perfect) tool as autotools/mvn/.... but I guess this is too idealistic and simplified thinking as there is definitively some reasonable explanation behind current state.

On the other hand nothing prevents anyone(locally) from running the build scripts with higher privileges or relaxing write protection of system paths(which is definitively not recommended and I will be strongly against it at distribution level) to full fill kube's buildscripts assumptions (or somehow hack in custom pkgdir,... etc.).

Note You need to log in before you can comment on or make changes to this bug.