Allow users to use multistage Docker builds based on Docker version

[estroz]

Description of the change: if docker version >= 17.05 is present, allow users to generate a multistage Dockerfile build/multistage.Dockerfile using operator-sdk build --gen-multistage and use it in building. The SDK will detect whether both docker version >=17.05 is available and a multistage Dockerfile is present, and if the former is true but not the latter will generate a warning to upgrade using --gen-multistage. The warning directs users to move rename multistage.Dockerfile to Dockerfile to avoid the warning in the future. Multistage Dockerfiles are used in tests too.

Motivation for the change: some users might not be restricted by RHEL docker versioning, so they should be able to build Go binaries in a consistent environment. The only way to do so currently is with multistage builds. We should push users with docker version >= 17.05 towards using a multistage build with a warning, but not necessarily require it. This solution creates multistage Dockerfiles for both operator and test binaries.

Closes #167

[estroz]

While this PR passes CI, multistage builds cause the memcached e2e test to run for 400 seconds, which normally run in 250 seconds. I tested these changes locally and the result is 220 vs 200 seconds for multistage and non-multistage, respectively. With an increased timeout, the total build time for Go e2e CI with these changes is ~17 minutes, ~3 minutes more than non-multistage. I originally thought this was a buildah issue but it appears to affect both buildah and docker multistage builds in travis VM's. Locally there are no issues.

[joelanford]

LGTM overall. Just a few typos to fix and some nits.

[hasbro17]

/hold

There is some more discussion that we need to have around managing multiple layers of Dockerfiles #431 and how we update the Dockerfile for a hybrid operator #670 before we see how a multistage Dockerfile fits into that solution.

We definitely want multistage Dockerfiles but before we open that door and push users to multistage, we need to be clear on how we support multiple base images(single vs multiple Dockerfiles) and how the SDK can control the Dockerfile for any changes that it needs while still allowing the user to add custom build steps.

[openshift-bot]

@estroz: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[estroz]

I only copy internal/pkg here because internal/util has dependencies that memcached-operator does not satisfy, which causes a build error. This is a temporary workaround until #1001 is merged, since go mod can resolve non-master commits.

[estroz]

This PR works locally but for some reason e2e tests experience a SIGQUIT timeout in Travis.

[AlexNPavel]

@estroz The default go test timeout is 10 minutes and it's taking more than that do run the tests. In a dual core minikube instance on my laptop it takes 7.5 minutes. The oc cluster is slower than minishift and travis is slower than my laptop's minikube vm, so these tests take too long.

[lilic]

If that is the only problem can't we just set the timeout e.g. go test -timeout 20m?

[estroz]

@lilic travis will send a SIGQUIT if there's no test output for more than 10 minutes. I added a travis_wait 20m to the travis config and still no luck.

I'm going to put off this PR until we can figure out a CI solution for slow containerized binary builds.

/hold

[chrsoo]

@lilic travis will send a SIGQUIT if there's no test output for more than 10 minutes.

@estroz there is no way to refactor the tests to produce output during their execution? Or is this due to a limitation of travic/go test? Can the go test be split in several invocations?

[estroz]

@chrsoo limitations are in image build speed and go test logging. Travis VM's are fairly slow, which combined with slow building of binaries in docker containers results in much longer build times. As of now there's no log streaming from go tests, but they're working on it. Hopefully it'll be in go 1.13 or 1.14.

A workaround in the mean time is to copy the multistage builder Dockerfile into build/Dockerfile (and the test Dockerfile into build/test-framework/Dockerfile if you're running e2e tests). Then operator-sdk build will build your operator images using multistage builds, assuming you have docker 17.05+.

[openshift-ci-robot]

@estroz: PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.