Remove constraints and update all vendor pkgs

[msau42]

I am removing k8s constraints so that it's hopefully easier to update external-provisioner k8s dependencies. I think this is safe to do now since the APIs that snapshotter needs are in official releases. If there is a need in the future to set a constraint on an specific version, then we can add it at that point. I also want to make more progress on #60 so that the external-provisioner doesn't have to import external-snapshotter, only the apis.

Edit: since snapshotter still depends on alpha APIs, it's easier to handle breaking alpha changes if all the k8s packages are on the same release. So I am fixing all the k8s dependencies to release-1.14 so we can unblock external-provisioner

[msau42]

/assign @xing-yang @jingxu97
can one of you help test this?

[xing-yang]

I don't think it is right to get rid of K8S dependencies in this project. It does depend on in-tree APIs.

[msau42]

K8s APIs should be stable. The exception is the alpha PVC data source field. However, I think if that API does ever break, we will know about it because compilation will fail, and at that time then we can add the constraint if we don't want to fix it.

[msau42]

Also it should be noted that by not specifying any constraints, dep will try to find the latest tagged version to use. If there are no tags that follow semantic versioning, only then will it use master head.

[msau42]

I brought up an alpha cluster and ran the Snapshot e2es with my private image and they passed:

Ran 2 of 3260 Specs in 130.989 seconds
SUCCESS! -- 2 Passed | 0 Failed | 0 Pending | 3258 Skipped PASS

Ginkgo ran 1 suite in 2m13.104037756s
Test Suite Passed
2019/03/10 13:44:08 process.go:155: Step './hack/ginkgo-e2e.sh --ginkgo.focus=VolumeSnapshotDataSource' finished in 2m14.479080652s

[xing-yang]

I still don't think we should remove k8s constraints from this repo. If all repos under kubernetes-csi have k8s constraints removed, I would consider that is the common practice for kubernetes-csi repos (even though it is still unusual in general). I don't think external-snapshotter repo should be handling k8s constraints so differently.

[msau42]

I intend to go clean up all the sidecars, but am starting with snapshotter first because it's blocking external provisioner updates.

It took me a while to understand the basic concepts of dep as it different from other dependency management paradigms. One major concept is that the updates to existing packages are controlled: the lock file fixes the version, until you explicitly run "dep ensure -update". That way you can thoroughly test out any vendor update before committing them, and also on your own timeline.

As I understand it, there are two main reasons to have a constraint:

• You need to pull in a build that has not been officially tagged yet
• You are dependent on some API or behavior in some older release and you cannot update your application to use the latest

As I understand it, the constraints on k8s were added originally because we needed to pull in k8s API changes that were not officially released yet. But now that they are, I think it is fine to remove the constraint and pull in the latest official releases. K8s apis have a well defined deprecation policy, and the apis we depend on are also ones that we maintain so we can coordinate any potential future changes. I don't think the current status of snapshotter needs any of the two reasons which is why I think it is safe to remove the constraints now. We always have the option to add it back in the future if we need to.

[msau42]

Set all the constraints to release-1.14. Tested private image with e2es and they passed.

[xing-yang]

I still don't think constraints should be removed. Can you remove this line please? Also we are still working on designing new features such as ExecutionHook and PVC taints that could impact in-tree APIs, so that could affect the dependencies on in-tree APIs too.

[msau42]

They impact the dependencies right now because it's an alpha feature and k8s doesn't offer any compatibility guarantees for alpha features. But once an API is GA, then it's very hard to change it. I agree that while snapshotter is using alpha APIs, then we may have compatibility issues.

[msau42]

Since snapshotter is still in alpha and is undergoing significant changes, I will remove this line. But once the API and feature is stable, I would strongly encourage reconsidering this

[xing-yang]

Is this the latest stable branch that supports k8s 1.14?

[msau42]

yes, the 10.0 release supports k8s 1.13, so the 11.0 is for 1.14.

[xing-yang]

/lgtm

[xing-yang]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: msau42, xing-yang

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 [xing-yang]

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