Skip to content
This repository has been archived by the owner on Nov 8, 2022. It is now read-only.

Design discussions #2

Closed
andrzej-k opened this issue Apr 19, 2016 · 1 comment
Closed

Design discussions #2

andrzej-k opened this issue Apr 19, 2016 · 1 comment

Comments

@andrzej-k
Copy link
Contributor

This is the place to discuss any aspects regarding PoC design. All decision will be recorded here: https://github.com/intelsdi-x/kubesnap/wiki/Design

@andrzej-k
Copy link
Contributor Author

andrzej-k commented Apr 22, 2016

As for the format/structure of data exposed by snap it would be same as currently exposed by kubelet.

The raw metrics (from kubelet) can be queried like this: curl <kubelet IP>:10255/stats/
The raw metrics (from snap) could be queried like this: curl <kubelet IP>:10555/stats/

This will allow to re-use parser methods (decodeMetrics) used on the heapster side. The alternative would be a snap specific format which would require new parser on heapster side - for PoC it seems that re-using existing parser would be faster and less error prone.

For the PoC there will be a new heapster publisher plugin which will expose data in the format exposed currently by the kubelet.

In the future there could be:

  • a processor plugins which will re-format data exposed by snap collectors to k8s format
  • a publisher plugin which will get the data (in k8s format) from the processor plugin to expose them via REST API

Having dedicated processor to adapt snap metrics to k8s format would allow to exchange publisher if needed.

@IzabellaRaulin @jcooklin @fgrzadkowski @piosz @mwielgus

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant