vendor: Update to 1.10

[gaocegege]

/assign @johnugeorge

/cc @zjj2wry

---

This change is 

[gaocegege]

/cc @jlewi @richardsliu

Should we follow the convention of the k8s community and keep multiple branches (release-1.9, release-1.10)? Or we just merge it into master directly?

[coveralls]

Coverage increased (+0.1%) to 57.181% when pulling 70fdd04 on gaocegege:1.10 into 9c24967 on kubeflow:master.

[coveralls]

Coverage increased (+0.04%) to 57.075% when pulling df02e5a on gaocegege:1.10 into 9c24967 on kubeflow:master.

[johnugeorge]

/lgtm

[jlewi]

What are we upgrading to 1.10? The K8s client library? Why are we upgrading it? Are there specific features we want that are only in 1.10?

What does this mean in terms of the K8s versions we can work with? Can we still run on older versions of Kubernetes? e.g. 1.9?

[gaocegege]

We can run in 1.9, this PR just upgrades vendor. We expect this upgrade because if your project depends on tf-operator and k8s code, k8s in vendor is 1.10, and tf-operator relies on k8s 1.9, then there is conflicts in vendor. The best way to solve it is to maintain multiple branches like https://github.com/kubernetes/code-generator/tree/release-1.10.

BTW, this is about development and does not affect usage. Users can run the operator in 1.9 or 1.10 or above.

[jlewi]

Thanks for the explanation.

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: jlewi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [jlewi]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment