Fabian Reinartz

Related to this, we should not parse YAML directly: http://ghodss.com/2014/the-right-way-to-handle-yaml-in-golang/ Instead use: https://github.com/ghodss/yaml – also how Kubernetes handles it. What we have to watch out for is keeping the validation...

Yes. Performance optimisation is nice – realistically most metrics have labels though. So I wouldn't even prioritise that.

Cool, I'm very much in favor of this. > Performance/allocation penalty of the slice interface is not overly relevant as registration and collection happens relatively rare. (Exception would be high-frequency...

Well, I think our querying doesn't really provide a way to "enter" a namespace and I don't really see it as necessary. There are just too many metrics that change...

I agree that more examples would are necessary and that blog posts come with the issue of going out of date. I'm strongly in favor for keeping the core docs...

Seems very hard to get adopted. Per-exporter parameters to enable certain collectors seems more useful an independent in general. So far number of metrics in collection didn't seem to be...

I agree with that. Whatever I'm monitoring, I'll have to look up valid values for whatever parameters anyway – might just as well use parameters given in the docs. "Collectors"...

It seems that the [census-ecosystem Stackdriver exporter for Go](https://github.com/census-ecosystem/opencensus-go-exporter-stackdriver/) fixes one issue described above. What is the relationship between the exporters in this Github org and the implementations directly in...

The tailer keeps retrying to read more data until its context get canceled. Currently the test waits a fixed amount of time until it cancels after writing the last record....

We have definitely thought about that use case and want to enable it. Though we don't have a concrete design yet on how to integrate that with the current CRDs....