Federation users shouldn't be required to have go compiler toolchain/libraries installed

[madhusudancs]

It is unfortunate that our federation turn up scripts run the manifests through a go program which isn't shipped as a binary in our release, but instead as a source. This means that our users are required to have the go toolchain installed and configured to even try out federation. We should fix this.

It is also quite amusing that e2es did not catch this. Do we have go toolchain installed on the Jenkins machine that deploys the test clusters?

cc @colhom @ixdy @kubernetes/sig-cluster-federation

[colhom]

@madhusudancs the go toolchain has always been a hard dependency for kubernetes-e2e Jenkins jobs since prior to the existence of federation. There is e2e-runner and a dockerized-e2e-runner, both of which are bash scripts with do bring-up, e2e test themselves, reporting, and tear-down. This is all actuated via go run ./hack/e2e.go, and as you'd expect both require a working golang installation be available to the context interacting the the kubernetes/ folder.

If we want to fix this anti-pattern of treating golang source files as scripts (the existence of go run command suggests that it's not an anti-pattern...but I digress) , we should take any of the go utilities that aren't codegen related (e2e.go, template.go, ... there are probably more), stuff them all in a package and add them to the release target.

\cc @quinton-hoole

[ghost]

@colhom , @madhusudancs I think that you both have good points. Here's my take:

1. The e2e status quo relies on the go toolchain, and we should leave it as such (or fix it holistically, and independently of federation).
2. We should also support a pre-built binary release of federation, which can be installed with minimum external dependencies (including the go toolchain). This would be consistent with the Kubernetes binary installation e.g. http://kubernetes.io/docs/getting-started-guides/gce/

[madhusudancs]

@quinton-hoole @colhom agreed on all your points (@colhom except the point on the existence of go run indicating a pattern. I will be happy to discuss about that outside this issue).

My intention, and this issue, is not about fixing e2e's dependency on go toolchain. In some sense it really doesn't matter whether e2e's have go toolchain dependency or not. I was amused that there was a dependency because I was hoping that the jenkins jobs were directly calling the shell scripts, not the go wrappers. But anyway, don't want to get sidetracked.

We should, however, definitely not expect our users to have the go toolchain installed.

[ghost]

@madhusudancs Just confirming that we can get this in by tomorrow as previously discussed. It's pretty critical for usability.

[madhusudancs]

@quinton-hoole I think so, yes. PR #30744 is the only blocking PR as far as I remember.

[nikhiljindal]

@madhusudancs https://github.com/kubernetes/kubernetes/pull/30744 is now merged. Next step I think is to write a doc explaining the new flow and put it on k8s.io?

[madhusudancs]

@nikhiljindal yes!

[ixdy]

I was OOO when this issue was first discussed.

I think @fejta is working on getting rid of the go requirement for hack/e2e.go. That said, we only expect devs to be using hack/e2e.go, so requiring the go toolchain to be installed seems reasonable.

[madhusudancs]

@ixdy this issue isn't about devs. Current federation scripts that we ship in the release distribution require users (end users) to have go toolchain installed to install federation. That's not reasonable.

[ixdy]

@madhusudancs agree 100%. I saw you mention hack/e2e.go, but I see now that that was mostly to explain why we have the go toolchain available in CI.

[pwittrock]

@quinton-hoole @madhusudancs @ixdy

I am leaving this in the 1.4 release as a blocking issue. Please provide daily status updates to this issue or move it out of the release and into v1.4-nonblocking where it will no longer be tracked as a release blocking issue in the burndown meetings.

[madhusudancs]

@pwittrock The relevant code is merged. There is only documentation work left and I am keeping this open as a reminder. How would you like us to track this?

[pwittrock]

move it out of the release and into v1.4-nonblocking where it will no longer be tracked as a release blocking issue in the burndown meetings.

[madhusudancs]

@pwittrock Ok, thanks!

[irfanurrehman]

This issue was labelled only for sig/multicluster and is thus moved over to kubernetes/federation#55. If this does not seem to be right, please reopen this and notify us @kubernetes/sig-multicluster-misc. /close