Kubelet Client and API types

[DirectXMan12]

Kubelet exposes the stats API (https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/api/v1alpha1/stats) as well as an associated client (https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/client). Heapster uses these to talk to the the legacy stats API and the summary API (see https://github.com/kubernetes/heapster/tree/master/metrics/sources/kubelet and https://github.com/kubernetes/heapster/tree/master/metrics/sources/kubelet).

Having those API types and the client code here (or in a separate repo) would be useful, since it would work towards removing the circular dependency between Heapster and Kubernetes.

cc @deads2k @lavalamp

[DirectXMan12]

@dashpole's proposed "Core Metrics API" (kubernetes/community#252) will most likely have a similar issue.

In the longer term, the API definitions for the metrics APIs shouldn't live in Heapster, but not requiring Heapster to vendor k8s proper would be nice in and of itself (seeing as it's a client of Kubernetes, mainly, that happens to take advantage of some of the shared API server code that's being split out).

[deads2k]

This client project may just be for speaking to an API server, but this does highlight a need to do something similar for the kubelet or to break the kubelet out of k8s.io/kubernetes to avoid the cycle.

[lavalamp]

I think once we're developing the client in a separate repo we could actually do this but it would make things even more convoluted to add it in right now? I could be wrong. I'm not opposed to this.

…

On Fri, Jan 20, 2017 at 5:25 AM, David Eads ***@***.***> wrote: This client project may just be for speaking to an API server, but this does highlight a need to do something similar for the kubelet or to break the kubelet out of k8s.io/kubernetes to avoid the cycle. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAngloGpI18Renq44VS9IqqWnrn5VyqEks5rULXLgaJpZM4Lourv> .

[deads2k]

I think once we're developing the client in a separate repo we could
actually do this but it would make things even more convoluted to add it in
right now? I could be wrong. I'm not opposed to this.

It might not be too bad in 1.6 (february). We're actually getting pretty close to eliminating most of the code vendored from k8s.io/kubernetes.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[DirectXMan12]

We've got our own copy in Heapster for the moment, and that's "ok" until something changes with those APIs, since this issue isn't going anywhere.

[yashbhutwala]

Discovered this issue while trying to #716. @DirectXMan12 or @deads2k, any updates on integrating the clients?