Rebase onto Kubernetes 1.6-candidate

[pmorie]

We should rebase onto a release candidate for Kubernetes 1.6 after we're at MVP-1. There are a couple things we can only do after this is done:

1. Make our API written purely in terms of client-go
2. Consume the e2e framework from k8s

Ideally, we would be able to drop out dependency on k8s after the next rebase. It's worth analyzing all the packages we import from k8s to determine if any packages needs to be moved to one of the machinery repos to enable this.

[pmorie]

I volunteer to do this once the dust settles on completing the MVP 1 functionality.

[pmorie]

Another nasty effect of the current situation:

There are two different 'testing' packages imported from kubernetes projects in unit tests that need to use fake clients for both the service catalog and kubernetes core APIs:

• k8s.io/kubernetes/client/testing/core
• k8s.io/client-go/1.5/testing

These are the same package, but we have to import them from both locations because our API is written using packages from kubernetes directly, while for the kubernetes core API, we use client-go.

We have to do this for now because the version of kubernetes we vendor in for the API server guts uses the kubernetes packages. Once we rebase onto the latest kubernetes repo, we'll be able to stop using the kubernetes/... packages entirely and just consume types from client-go.

[arschles]

This has been done in #596. closing