Gopkg.*,pkg/generator/templates.go: update to kubernetes 1.11.2

[wongma7]

this continues #391 @hasbro17 PTAL

[openshift-ci-robot]

Hi @wongma7. Thanks for your PR.

I'm waiting for a operator-framework member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

I understand the commands that are listed here.

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.

[wongma7]

    	memcached_test.go:223: Building operator docker image
    	memcached_test.go:226: error: exit status 1
    		Command Output: Error: failed to build: (building memcached-operator...
    		vendor/github.com/operator-framework/operator-sdk/pkg/k8sclient/client.go:31:2: cannot find package "k8s.io/client-go/restmapper" in any of:
    			/home/travis/gopath/src/github.com/example-inc/memcached-operator/vendor/k8s.io/client-go/restmapper (vendor tree)
    			/home/travis/.gimme/versions/go1.10.3.linux.amd64/src/k8s.io/client-go/restmapper (from $GOROOT)
    			/home/travis/gopath/src/k8s.io/client-go/restmapper (from $GOPATH)
    		)

[shawn-hurley]

@wongma7 @hasbro17 I think the test is failing because the generated operator is not using this branches SDK code.

What is the best way to either make the generated code point to this branch for the test or do we ignore e2e tests?

IMO we should consider updating the tests, to always pull the branch that is being tested of the sdk. But I don't know if we should block this PR?

/cc @AlexNPavel

[AlexNPavel]

This should be using our code, not sure why it is failing: https://github.com/operator-framework/operator-sdk/blob/master/test/e2e/memcached_test.go#L72
I'll look at this more in depth later and see if I can figure out what's going on

[hasbro17]

@shawn-hurley The e2e test actually does make sure that for the generated operator the current PR branch of the SDK is vendored.
https://github.com/operator-framework/operator-sdk/blob/master/test/e2e/memcached_test.go#L72-L73

The problem we're doing this post dep ensure which ran against the master branch of the SDK which does have a dependency on k8s.io/client-go/restmapper. So that's never added to the vendor.

If the initial dep ensure ran against this PR then k8s.io/client-go/restmapper would be a transitive dependency of pkg/sdk and would be added to the vendor.

It's always always a bit tricky when we update pkg/sdk that introduces new transitive dependencies.

[hasbro17]

I think we can fix how we run this test and have it run dep ensure against this PR and then get the correct transitive dependencies.

Instead of just replacing the vendored SDK directory directly after running dep ensure, we can have the test get the Git-SHA or revision of the current PR and update the test-operator's Gopkg.toml to use the current PR's revision.

PR_REVISION=git rev-parse HEAD
sed -i 's|branch = "master"|revision = "$PR_REVISION"|g' Gopkg.toml

# Run dep ensure to update the vendored SDK and its transitive deps with the current PR 
dep ensure

[shawn-hurley]

I think you're going to have to change the dep source as well, depending on travis variables, But I think this approach will be less error-prone IMO

[AlexNPavel]

Due to the way that dep works, we cannot fix this with dep (remote references like the ones github/travis use are not supported). We simple have to merge this and then check if travis's master build works.

[hasbro17]

Travis exposes the following envs:
TRAVIS_PULL_REQUEST_SHA gives us the HEAD of the current PR. We use this as the revision.
TRAVIS_PULL_REQUEST_SLUG gives us the owner_name/repo_name of the fork of the PR. We'll use this as the Source in for the sdk constraint.

So we can update the Gopkg.toml accordingly in our test to vendor the PR commit.

[AlexNPavel]

New PR open with fix ^

[hasbro17]

@wongma7 Can you please rebase your PR from master. With #525 we should be able to properly test your changes.

[wongma7]

rebased, ty for the quick response on this

[hasbro17]

The test is still failing but this time the operator is built and run successfully. Its just not reconciling correctly as we expect it to (i.e create a memcached deployment for a memcached CR).

@wongma7 Can you do a manual test with the example on the README/user-guide to test out if an operator with your changes can still watch and use the client correctly. I'm going to verify that myself.

[hasbro17]

After testing it manually I found the issue.
mapping.Resource is of type schema.GroupVersionResource and not of type string.

Replace lines 115-120:

gvr := &schema.GroupVersionResource{
		Group:    gvk.Group,
		Version:  gvk.Version,
		Resource: mapping.Resource.String(),
	}
	return gvr, nil

with:

return &mapping.Resource, nil

[wongma7]

thanks, fixed, works for me locally as well now

[shawn-hurley]

LGTM Thank you!

[AlexNPavel]

LGTM

[hasbro17]

LGTM