vendor: k8s.io/kubernetes/pkg/...@v1.5.3

[radeksimko]

The whole process involved more than just govendor add k8s.io/kubernetes/pkg/... & govendor fetch k8s.io/kubernetes/pkg/...@v1.5.3 because some dependencies were incorrectly parsed, so I had to add & fetch manually after editing the vendor.json & adding correct revisions.

With that said I did not touch any other files manually within the vendor/ folder.

Also I originally thought we could use https://github.com/kubernetes/client-go which is linked from https://github.com/kubernetes/community/blob/master/contributors/devel/client-libraries.md but the whole client-go library has broken dependencies in a way that it was very difficult for govendor to deal with. See kubernetes/client-go#83

This is why I decided to pick the library inside kubernetes/kubernetes which in turn probably involves more LOC generally - hence the 500k+ diff. 😞

The K8S provider PR will follow.

[jbardin]

LGTM

I wonder if we're going to need to break providers back out of terraform, simply to manage dependencies. This adds another 168 packages, each with their own possibility of version conflicts.

I wasn't a fan of the pile of binaries we had pre 0.7, but this is starting to look unmaintainable.

[radeksimko]

I agree with you, although I think K8S is kind of a special case, also because it's supposed to do a lot of things ™️ , some of which are probably overlapping with Terraform - e.g. management of volumes for many different providers.

Also I really hope that one day the kubernetes/client-go will be more stable and that might reduce the LOC slightly.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.